From curtis@occnc.com Sun Sep 2 13:08: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 111FF21F84E2 for ; Sun, 2 Sep 2012 13:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.416 X-Spam-Level: X-Spam-Status: No, score=-2.416 tagged_above=-999 required=5 tests=[AWL=0.184, 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 X8ybE39zO3qF for ; Sun, 2 Sep 2012 13:08:22 -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 EC93521F84DE for ; Sun, 2 Sep 2012 13:08:21 -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 q82K8HQF085262; Sun, 2 Sep 2012 16:08:17 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201209022008.q82K8HQF085262@gateway2.orleans.occnc.com> To: Richard Mortier From: Curtis Villamizar In-reply-to: Your message of "Sat, 01 Sep 2012 07:36:13 BST." Date: Sun, 02 Sep 2012 16:08:17 -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: Sun, 02 Sep 2012 20:08:23 -0000 In message Richard Mortier writes: > (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? If the client does not have a configured trust anchor (for anything, DNSSEC included) and is getting one from a discovered source on the local network, then anything signed with it is inherently untrustworthy. The example (provided earlier on this thread) where whitehouse.gov and billthecat.whitehouse.gov are successfully spoofed *and* are DNSSEC signed is an example of a "signed untrustworthy source". > > 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. Does the client have a configured trust anchor for the global service? if either signpost or DNSSEC is using a trust anchor that is discovered dynamically, you have a huge security hole. > -- > Richard Mortier > mort@cantab.net Curtis From richard.mortier@gmail.com Thu Sep 6 14:46: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 AC6A221F85C3 for ; Thu, 6 Sep 2012 14:46:00 -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 73XNVz21bwn6 for ; Thu, 6 Sep 2012 14:46:00 -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 CF5D521F854C for ; Thu, 6 Sep 2012 14:45:59 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2183271vbb.31 for ; Thu, 06 Sep 2012 14:45:59 -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=SfZw1lkMuAE/+LGEauhA60bJb1AmKxhD9DBZZ547Zvs=; b=ug6ZemeeFXd9fKnbu8tqBtTJjEc+7gp+vQfZGo0mM2nnioiarrc5uimFw61fanv6wB 23yriWXMppZkS+uSgALl3soSuHIQ9QQ2AIL3mu68z8DAtLMoqZ04Ds9LQgG0jATdw5Fp G2ZvVUJ1xps3oGjfhmkG+CnvRhU6xSbPnes7xi1t8U51H/8YLAd5eZ4S+ZCn8kGkKTXg +ocPFr7DRmKUEFlvcJ4qViuWmOEQLebO1FRDnyxqUrIzqyb5r/w2kzvZYN3J1Nq3kNpu XMf+PvaQq+hRefDlzK/ilXciKVbZRodgjhzLwM5mVIAPTPctrTnyfHHmV6r3n6373jz0 dG1w== MIME-Version: 1.0 Received: by 10.220.37.194 with SMTP id y2mr4284652vcd.44.1346967959181; Thu, 06 Sep 2012 14:45:59 -0700 (PDT) Sender: richard.mortier@gmail.com Received: by 10.58.136.199 with HTTP; Thu, 6 Sep 2012 14:45:59 -0700 (PDT) In-Reply-To: <201209022008.q82K8HQF085262@gateway2.orleans.occnc.com> References: <201209022008.q82K8HQF085262@gateway2.orleans.occnc.com> Date: Thu, 6 Sep 2012 22:45:59 +0100 X-Google-Sender-Auth: 6hLxFe5-jjOZAfYRvzTIbIkNSD0 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: Thu, 06 Sep 2012 21:46:00 -0000 On 2 September 2012 21:08, Curtis Villamizar wrote: > > In message > Richard Mortier writes: > ... >> not sure what you mean here - could you expand? > > If the client does not have a configured trust anchor (for anything, > DNSSEC included) and is getting one from a discovered source on the > local network, then anything signed with it is inherently > untrustworthy. The example (provided earlier on this thread) where > whitehouse.gov and billthecat.whitehouse.gov are successfully spoofed > *and* are DNSSEC signed is an example of a "signed untrustworthy > source". ah- thanks. i didn't fully understand the example i think. ... >> 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. > > Does the client have a configured trust anchor for the global service? > if either signpost or DNSSEC is using a trust anchor that is > discovered dynamically, you have a huge security hole. we expect that your globally addressable signpost domain is within the global dnssec hierarchy (eg., laptop.mort.io, tv.home.mort.io), and so can use "." as the trust anchor in the first instance, in the same way that other dnssec domains do. to use a local signpost, you should have previously connected to your global signpost to acquire the necessary trust anchor(s) over a secure (private, authenticated) channel. does that make sense? i'm not a security person by training, so it is very useful to get some comment/critique from someone with a deeper understanding of dnssec/security concerns... -- Richard Mortier mort@cantab.net From curtis@occnc.com Fri Sep 7 19:02: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 B783921F8512 for ; Fri, 7 Sep 2012 19:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.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 frLwIVS+eb9F for ; Fri, 7 Sep 2012 19:02:33 -0700 (PDT) Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id D4D1E21F8510 for ; Fri, 7 Sep 2012 19:02:32 -0700 (PDT) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id q8822OC3003287; Fri, 7 Sep 2012 22:02:24 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201209080202.q8822OC3003287@gateway1.orleans.occnc.com> To: Richard Mortier From: Curtis Villamizar In-reply-to: Your message of "Thu, 06 Sep 2012 22:45:59 BST." Date: Fri, 07 Sep 2012 22:02:24 -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: Sat, 08 Sep 2012 02:02:33 -0000 In message Richard Mortier writes: > On 2 September 2012 21:08, Curtis Villamizar wrote: > > > > In message > > Richard Mortier writes: > > > ... > >> not sure what you mean here - could you expand? > > > > If the client does not have a configured trust anchor (for anything, > > DNSSEC included) and is getting one from a discovered source on the > > local network, then anything signed with it is inherently > > untrustworthy. The example (provided earlier on this thread) where > > whitehouse.gov and billthecat.whitehouse.gov are successfully spoofed > > *and* are DNSSEC signed is an example of a "signed untrustworthy > > source". > > ah- thanks. i didn't fully understand the example i think. > > ... > >> 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. > > > > Does the client have a configured trust anchor for the global service? > > if either signpost or DNSSEC is using a trust anchor that is > > discovered dynamically, you have a huge security hole. > > we expect that your globally addressable signpost domain is within the > global dnssec hierarchy (eg., laptop.mort.io, tv.home.mort.io), and so > can use "." as the trust anchor in the first instance, in the same way > that other dnssec domains do. > > to use a local signpost, you should have previously connected to your > global signpost to acquire the necessary trust anchor(s) over a secure > (private, authenticated) channel. > > does that make sense? i'm not a security person by training, so it is > very useful to get some comment/critique from someone with a deeper > understanding of dnssec/security concerns... Yes as long as the "acquire the necessary trust anchor(s) over a secure (private, authenticated) channel" step makes use of a *configured* key or certificate that insures the other side is not spoofed. It can be somewhat like the configured certificates that come with your browser implementation. If so, then in this regard the signpost scheme adds nothing to using DNS with DNSSEC. It is also very much unlike mDNS or any scheme in which a local authority is discovered which may or may not be trustworthy. Another point I had made earlier is that absent NAT (as IPv6 should be), signpost adds little or nothing of value to DNS with DNSSEC. At least it adds little or nothing of value besides NAT support that I could find in (an admittedly brief read of) the URLs cited and add nothing that anyone has been able to articulate on this list other than NAT support that IPv6 should never need. > -- > Richard Mortier > mort@cantab.net Curtis From Ray.Bellis@nominet.org.uk Mon Sep 10 05:34: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 2B4BE21F8650 for ; Mon, 10 Sep 2012 05:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 6bv58b+a0Vit for ; Mon, 10 Sep 2012 05:34:29 -0700 (PDT) Received: from mx4.nominet.org.uk (mail.nominet.org.uk [213.248.199.24]) by ietfa.amsl.com (Postfix) with ESMTP id 3D09E21F865D for ; Mon, 10 Sep 2012 05:34:29 -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:Content-ID:Content-Transfer-Encoding: MIME-Version; b=l3X/F0/rNcJfdiIqMuxCVe2dD1vPVMnDrbdw1Mrh8fYkZ6ZS4fyCxHEU 8vH8tkGVxtEyGJ+DtEvYkXcnUZCSf4Q233I+JuaTtd/iWs0BULKkr33dU XEH/vKxyrTkjf9w; 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=1347280469; x=1378816469; 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:=20Unicast=20DNS=20within=20the=20Homenet?|Date: =20Mon,=2010=20Sep=202012=2012:34:21=20+0000|Message-ID: =20<47437C06-FB3D-41AB-ADB9-01A4091640E1@nominet.org.uk> |To:=20"homenet@ietf.org=20Group"=20 |MIME-Version:=201.0|Content-Transfer-Encoding:=20quoted- printable|Content-ID:=20<9b3272f1-e88c-4bee-bf84-12f14e77 3d34>; bh=0qVtw3LDV8rEMSvQXyDsr5kqkijDjif949afg0nQ8F8=; b=W5iy2viw1Co4sQixtiFYoca66INpcZjlTx4HqLF62AjrV5O8D1Tych1E 35lbAzobERDaGvfXdHAGIC+lf5Hc9T36Um5kjI7e9N9ijGieC7dijQKf4 MQ6Ic3xvs0yziMN; X-IronPort-AV: E=Sophos;i="4.80,398,1344207600"; d="scan'208";a="35414635" Received: from wds-exc1.okna.nominet.org.uk ([213.248.197.144]) by mx4.nominet.org.uk with ESMTP; 10 Sep 2012 13:34:23 +0100 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f%19]) with mapi; Mon, 10 Sep 2012 13:34:22 +0100 From: Ray Bellis To: "homenet@ietf.org Group" Thread-Topic: Unicast DNS within the Homenet? Thread-Index: AQHNj1CaMae+5UCFKUqV53CEXv27Lw== Date: Mon, 10 Sep 2012 12:34:21 +0000 Message-ID: <47437C06-FB3D-41AB-ADB9-01A4091640E1@nominet.org.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <9b3272f1-e88c-4bee-bf84-12f14e773d34> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [homenet] Unicast DNS within the Homenet? 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, 10 Sep 2012 12:34:30 -0000 An interesting question has come up during the Arch Doc team's discussions = around naming and service discovery: "What in-home services actually require Unicast DNS lookup?" [*] The one obvious case is in-home web servers (i.e. CPE configuration) althou= gh a prior posting suggested that most people just use an IPv4 address (e.g= . 192.168.1.1) rather than a DNS name for that. Many devices now support B= onjour for that. If it can be shown that Unicast DNS is only need for resolution of _externa= l_ names then much of the discussion around _internal_ naming probably beco= mes moot. thanks, Ray [*] I'm specifically _not_ talking about normal recursive DNS for global DN= S names.= From Hans_Liu@dlink.com.tw Mon Sep 10 05:39:43 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BF2C21F8692 for ; Mon, 10 Sep 2012 05:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.644 X-Spam-Level: X-Spam-Status: No, score=0.644 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_TW=1.335, RCVD_ILLEGAL_IP=1.908] 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 Y2W42sf8yyy1 for ; Mon, 10 Sep 2012 05:39:42 -0700 (PDT) Received: from smtp-tp2.dlink.com.tw (smtp-tp2.dlink.com.tw [60.248.210.36]) by ietfa.amsl.com (Postfix) with ESMTP id 8E73421F8691 for ; Mon, 10 Sep 2012 05:39:42 -0700 (PDT) Received: from HCB-HUB1.dlink.com.tw (localhost.localdomain [127.0.0.1]) by smtp-tp2.dlink.com.tw (Postfix) with ESMTP id 1B1D0873B3; Mon, 10 Sep 2012 20:39:31 +0800 (CST) Received: from MBS-HQ1.dlink.com.tw ([fe80::d145:65e8:91b9:88a0]) by HCB-HUB1.dlink.com.tw ([::1]) with mapi id 14.01.0289.001; Mon, 10 Sep 2012 20:39:39 +0800 From: Hans Liu To: Ray Bellis Thread-Topic: [homenet] Unicast DNS within the Homenet? Thread-Index: AQHNj1CaMae+5UCFKUqV53CEXv27L5eC/fAA Date: Mon, 10 Sep 2012 12:39:39 +0000 Message-ID: References: <47437C06-FB3D-41AB-ADB9-01A4091640E1@nominet.org.uk> In-Reply-To: <47437C06-FB3D-41AB-ADB9-01A4091640E1@nominet.org.uk> Accept-Language: zh-TW, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [1.160.230.149] Content-Type: text/plain; charset="us-ascii" Content-ID: <95B0AC22B35D014C9A543753B28B927D@exs.dlink.com.tw> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Unicast DNS within the Homenet? 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, 10 Sep 2012 12:39:43 -0000 FYI !! All of D-Link home routers now support NetBIOS name, mDNS and LLMNR= . We removed 192.168.0.1 from device label and Quick Installation Guide al= ready.=20 Best regards, Hans On Sep 10, 2012, at 8:34 PM, Ray Bellis wrote: An interesting question has come up during the Arch Doc team's discussions = around naming and service discovery: "What in-home services actually require Unicast DNS lookup?" [*] The one obvious case is in-home web servers (i.e. CPE configuration) althou= gh a prior posting suggested that most people just use an IPv4 address (e.g= . 192.168.1.1) rather than a DNS name for that. Many devices now support B= onjour for that. If it can be shown that Unicast DNS is only need for resolution of _externa= l_ names then much of the discussion around _internal_ naming probably beco= mes moot. thanks, Ray [*] I'm specifically _not_ talking about normal recursive DNS for global DN= S names. _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet From brian.e.carpenter@gmail.com Mon Sep 10 05:58: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 31D0021F8694 for ; Mon, 10 Sep 2012 05:58:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.629 X-Spam-Level: X-Spam-Status: No, score=-101.629 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, 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 eZ3tmDM0cnoY for ; Mon, 10 Sep 2012 05:58:48 -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 7F71F21F86A4 for ; Mon, 10 Sep 2012 05:58:48 -0700 (PDT) Received: by eaai11 with SMTP id i11so892887eaa.31 for ; Mon, 10 Sep 2012 05:58: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=A2tUc7VUARcL+SfZGKRANT7UQhXJ1Im/FNLa4h0Lnz0=; b=OIV9S77IU7l3+GIsUCI9Lf3fTZ1E0tjjqoVacfOdkeiMVIWFHl2QYv3KHi6h1ZOi3W O0Y2MNalMla2VHZKXVdthTyDZyqdyLyZKASHW6rstOakfvzDLSH1EDFrK2uMKcvXkPr6 ELnYS3hGFVtmvcFgsxD5oCs6FUOe56r7DOYNj6YJqUsBfHwuTJin1yks8nHw+yfmRX0A uAIn+bPqCA9324vvoqPbcFZ/piDeObTGJ3rY/cPbnfwRsfku6fR7fJS4+9O/rOa7YTKh x4fyRTdcPS4H7TS1tjdC4x0BUrsBiqhfauWMAQ+ZxlR2+8NqaoWoPZj14AOzCcQ1xOJO 70Pw== Received: by 10.14.213.201 with SMTP id a49mr19785176eep.4.1347281927656; Mon, 10 Sep 2012 05:58:47 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-218-175.as13285.net. [2.102.218.175]) by mx.google.com with ESMTPS id a7sm37932387eep.14.2012.09.10.05.58.45 (version=SSLv3 cipher=OTHER); Mon, 10 Sep 2012 05:58:46 -0700 (PDT) Message-ID: <504DE406.3050303@gmail.com> Date: Mon, 10 Sep 2012 13:58:46 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ray Bellis References: <47437C06-FB3D-41AB-ADB9-01A4091640E1@nominet.org.uk> In-Reply-To: <47437C06-FB3D-41AB-ADB9-01A4091640E1@nominet.org.uk> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Unicast DNS within the Homenet? 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, 10 Sep 2012 12:58:49 -0000 On 10/09/2012 13:34, Ray Bellis wrote: > An interesting question has come up during the Arch Doc team's discussions around naming and service discovery: > > "What in-home services actually require Unicast DNS lookup?" [*] Well, that isn't the right question IMNSHO. > The one obvious case is in-home web servers (i.e. CPE configuration) although a prior posting suggested that most people just use an IPv4 address (e.g. 192.168.1.1) rather than a DNS name for that. Many devices now support Bonjour for that. Using literal addresses is evil for many reasons - surely we don't need to discuss that ancient question again? > If it can be shown that Unicast DNS is only need for resolution of _external_ names then much of the discussion around _internal_ naming probably becomes moot. The right question is whether DNS is the appropriate solution for converting local devices names to addresses, or whether there is some other naming service that should be the standard. Since DNS is the IETF standard for converting names to addresses, there would need to be a pretty strong case for anything else. Brian From Ray.Bellis@nominet.org.uk Mon Sep 10 06:09: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 8D58C21F854F for ; Mon, 10 Sep 2012 06:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 7DEuYWmP+f6h for ; Mon, 10 Sep 2012 06:09:13 -0700 (PDT) Received: from mx3.nominet.org.uk (mail.nominet.org.uk [213.248.199.23]) by ietfa.amsl.com (Postfix) with ESMTP id 8998421F84EA for ; Mon, 10 Sep 2012 06:09:13 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:Content-Type: Content-ID:Content-Transfer-Encoding:MIME-Version; b=4lXr0J4+3ob/29EwLYzzneHrZMCqUBscbp9BBHKBC4wowREGGvCK/HUF Xxn8KFRMod6nVQTJSt1PpPeirdPHLnHXtzFOcZl97qbrsqRUpLkEz6IUA jRlklbZreqMx4tN; 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=1347282553; x=1378818553; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20Re:=20[homenet]=20Unicast=20DNS=20within=20th e=20Homenet?|Date:=20Mon,=2010=20Sep=202012=2013:09:11=20 +0000|Message-ID:=20<3C839850-3DAB-4797-91E4-9D036B70E158 @nominet.org.uk>|To:=20Brian=20E=20Carpenter=20|CC:=20"homenet@ietf.org=20Group"=20|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |Content-ID:=20<7079ad3a-cb87-4f6e-ab2f-6d460d7d1621> |In-Reply-To:=20<504DE406.3050303@gmail.com>|References: =20<47437C06-FB3D-41AB-ADB9-01A4091640E1@nominet.org.uk> =0D=0A=20<504DE406.3050303@gmail.com>; bh=1GFu92hab3g80ZfXAnl3BNXMzotL0JmOeCNhQFzEPMs=; b=02nXF4o32bJ2309M8s70FhOZktZGtLktHNJYq87fC1vN/Um9/XuZ7ylQ NRncJBaRCqwuNDVP98NEEuSKcszo0inEHYsxItwDpTm8kjdR83/bIT2d2 fefvBg41cRSe+60; X-IronPort-AV: E=Sophos;i="4.80,398,1344207600"; d="scan'208";a="43036336" Received: from wds-exc1.okna.nominet.org.uk ([213.248.197.144]) by mx3.nominet.org.uk with ESMTP; 10 Sep 2012 14:09:12 +0100 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f%19]) with mapi; Mon, 10 Sep 2012 14:09:11 +0100 From: Ray Bellis To: Brian E Carpenter Thread-Topic: [homenet] Unicast DNS within the Homenet? Thread-Index: AQHNj1QFKo5whUTqpEGPeXXUhoW/v5eDe4SA Date: Mon, 10 Sep 2012 13:09:11 +0000 Message-ID: <3C839850-3DAB-4797-91E4-9D036B70E158@nominet.org.uk> References: <47437C06-FB3D-41AB-ADB9-01A4091640E1@nominet.org.uk> <504DE406.3050303@gmail.com> In-Reply-To: <504DE406.3050303@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <7079ad3a-cb87-4f6e-ab2f-6d460d7d1621> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Unicast DNS within the Homenet? 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, 10 Sep 2012 13:09:14 -0000 On 10 Sep 2012, at 13:58, Brian E Carpenter w= rote: > Using literal addresses is evil for many reasons - surely we don't need t= o > discuss that ancient question again? I wasn't promoting it, just noting that this is the current position, with = Bonjour et al becoming the "preferred" way. The latter is "a good thing". > The right question is whether DNS is the appropriate solution for convert= ing > local devices names to addresses, or whether there is some other naming s= ervice that > should be the standard. Since DNS is the IETF standard for converting nam= es > to addresses, there would need to be a pretty strong case for anything el= se. The IETF has _other_ protocols for naming services (mDNS, LLMNR) that are d= esigned for local networks, albeit with the "wrong" multicast scope as far = as we're concerned. My question is therefore more about whether (internal) unicast DNS is actua= lly required at all. Ray From brian.e.carpenter@gmail.com Mon Sep 10 06:54: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 C977821F8691 for ; Mon, 10 Sep 2012 06:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.633 X-Spam-Level: X-Spam-Status: No, score=-101.633 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, 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 aVJfeDJWBLxh for ; Mon, 10 Sep 2012 06:54:03 -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 0CB0421F86A4 for ; Mon, 10 Sep 2012 06:54:02 -0700 (PDT) Received: by eekb45 with SMTP id b45so1196777eek.31 for ; Mon, 10 Sep 2012 06:54:01 -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=KCkull8HbcT2Aw7I/O1LUIyRgyZzBrRd1r41wMVeT6E=; b=qfNTxmDwrhpWFs98Pi1ygOYmcxOGulTPQZKQLWsE6mVesB7fCEN3jsVYNvL8siRGoZ uuP8BeOhet/KW7l27eqTq2cGVU3u/FR23TP2ihOy+7vzZ2KJPrQFhzwbYvIQU4llTrj1 lgAUhGBXjE7XiyvWzqMEcJ979aequKrE8V7W128zU8sjBdVDigpVie8gpImkMI07RNot mft4U0U4vqc0Ly0NEuejotUgHJF51TUgn6mvJsKY1cFX8ZPlrx8LoNtxzq+WQ3InsG8d Do5gy3133wTolxnBxvco4LnIod/Nmlj3T+/sMdsF2eCNzU1XzfKibfceXxyY3PFl7uTZ QnSQ== Received: by 10.14.4.198 with SMTP id 46mr20066529eej.11.1347285241224; Mon, 10 Sep 2012 06:54:01 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-218-175.as13285.net. [2.102.218.175]) by mx.google.com with ESMTPS id l42sm38398989eep.1.2012.09.10.06.53.59 (version=SSLv3 cipher=OTHER); Mon, 10 Sep 2012 06:54:00 -0700 (PDT) Message-ID: <504DF0F7.2050707@gmail.com> Date: Mon, 10 Sep 2012 14:53:59 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ray Bellis References: <47437C06-FB3D-41AB-ADB9-01A4091640E1@nominet.org.uk> <504DE406.3050303@gmail.com> <3C839850-3DAB-4797-91E4-9D036B70E158@nominet.org.uk> In-Reply-To: <3C839850-3DAB-4797-91E4-9D036B70E158@nominet.org.uk> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Unicast DNS within the Homenet? 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, 10 Sep 2012 13:54:07 -0000 On 10/09/2012 14:09, Ray Bellis wrote: > On 10 Sep 2012, at 13:58, Brian E Carpenter wrote: > >> Using literal addresses is evil for many reasons - surely we don't need to >> discuss that ancient question again? > > I wasn't promoting it, just noting that this is the current position, with Bonjour et al becoming the "preferred" way. The latter is "a good thing". afaik Bonjour is a proprietary protocol. How can that be a good thing? >> The right question is whether DNS is the appropriate solution for converting >> local devices names to addresses, or whether there is some other naming service that >> should be the standard. Since DNS is the IETF standard for converting names >> to addresses, there would need to be a pretty strong case for anything else. > > The IETF has _other_ protocols for naming services (mDNS, LLMNR) that are designed for local networks, albeit with the "wrong" multicast scope as far as we're concerned. And SLP, explicitly designed for locating services. > My question is therefore more about whether (internal) unicast DNS is actually required at all. And I'm saying that's the wrong question. I think the right question is whether there is an *open* standard for discovering service addresses from service names that is more suitable than DNS. Brian From ajs@anvilwalrusden.com Mon Sep 10 07:12: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 90A1D21F8694 for ; Mon, 10 Sep 2012 07:12:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.375 X-Spam-Level: X-Spam-Status: No, score=-0.375 tagged_above=-999 required=5 tests=[AWL=0.465, 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 WGhzOPvUrDcB for ; Mon, 10 Sep 2012 07:12:22 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 1D44B21F867E for ; Mon, 10 Sep 2012 07:12:22 -0700 (PDT) Received: from mx1.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 383888A031 for ; Mon, 10 Sep 2012 14:12:21 +0000 (UTC) Date: Mon, 10 Sep 2012 10:12:12 -0400 From: Andrew Sullivan To: homenet@ietf.org Message-ID: <20120910141212.GA84264@mx1.yitter.info> References: <47437C06-FB3D-41AB-ADB9-01A4091640E1@nominet.org.uk> <504DE406.3050303@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <504DE406.3050303@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [homenet] Unicast DNS within the Homenet? 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, 10 Sep 2012 14:12:22 -0000 On Mon, Sep 10, 2012 at 01:58:46PM +0100, Brian E Carpenter wrote: > The right question is whether DNS is the appropriate solution for converting > local devices names to addresses, or whether there is some other naming service that > should be the standard. Since DNS is the IETF standard for converting names > to addresses, there would need to be a pretty strong case for anything else. As Ray says, DNS is by no means the only IETF standard for this. There's RFC 4795, for instance. ALso, draft-cheshire-dnsext-multicastdns-15 has been in the RFC Editor queue for 265 days. There is an IPR disclosure, but it's your basic mutually-assured-patentwar-clause permissive license. Nevertheless, some people _do_ use real DNS -- even split-brain DNS -- in homenet-type networks. Certainly, the many devices that include dnsmasq (and yes, I am perfectly aware of the problems and limitations attendant on such deployments) are using DNS inside the network some of the time. I'd be pretty uncomfortable deciding that all those deployed networks are going to need reconfiguration to conform with whatever this WG comes up with. In addition, it seems to me that there are going to be split-brain overloaded-name conditions that are more easily solved with DNS than with anything else. (Certainly, the desire expressed several times in Vancouver for a single identifier simply to work no matter what network one is in suggests that things like llmnr and mdns are not going to be winners here.) Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From mike@mtcc.com Mon Sep 10 07:13:43 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 456D221F865B for ; Mon, 10 Sep 2012 07:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0KJ13bPROhc0 for ; Mon, 10 Sep 2012 07:13:42 -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 6024D21F8653 for ; Mon, 10 Sep 2012 07:13:42 -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 q8AEDeeR021116 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 10 Sep 2012 07:13:40 -0700 Message-ID: <504DF594.2000605@mtcc.com> Date: Mon, 10 Sep 2012 07:13: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: Brian E Carpenter References: <47437C06-FB3D-41AB-ADB9-01A4091640E1@nominet.org.uk> <504DE406.3050303@gmail.com> In-Reply-To: <504DE406.3050303@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=2365; t=1347286420; x=1348150420; 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:=20building=20a=20home=20theater |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=TzO4sW+DmvOIT+Wn6/4uP+57KebVuf77dT+PTmX32IA=; b=kbMQF62r9ogLaG9CpTJJ2G3/yG6Ig4TKD++pvbpZMZby8qSu9jM+ChZT/l RV4pG36P+calZ4mH4km4T1NEUR4/owCF2J35bO4VctL39m2W4q8fSv2il4gG 7j1WqUv4EvPQAQ3PZEqcC+lFWbgaQtNWVIbHV82c/bwjz6PKB9iuI=; 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 Bellis , "homenet@ietf.org Group" Subject: [homenet] building a home theater 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, 10 Sep 2012 14:13:43 -0000 On 09/10/2012 05:58 AM, Brian E Carpenter wrote: > > If it can be shown that Unicast DNS is only need for resolution of _external_ names then much of the discussion around _internal_ naming probably becomes moot. > The right question is whether DNS is the appropriate solution for converting > local devices names to addresses, or whether there is some other naming service that > should be the standard. Since DNS is the IETF standard for converting names > to addresses, there would need to be a pretty strong case for anything else. > > Maybe a thought experiment might help all of this along. In the very near future, I will probably be able to buy components and services like a display, an amp, anam/fm radio receiver, a cable/sat decoder, a jukebox-like disk server, speakers, lighting controls, internet based content services, and a popcorn popper. All IP enabled all wireless most likely. I want control these all from my phone, tablet or laptop where there the app brings all of these things together and wirelessly "wires" them all up much like banana plugs did before. I may want to have many different profiles of what constitutes a "theater" depending on whether I'm in the kitchen, on my lard-o-matic, or in a fully vegetative state on the couch. I need to be able to incrementally add components because I'm not rich, and I might want to add ad hoc components because my friends bring over some new gadget, or have content they'd like to source, etc. And I need to be able to have multiple different control points including possibly even allowing my friends to take control of the system as a whole. I generally want my app to control everything, but I am resigned to the fact that every once in a while I'm going to need to go to my speaker's web server and adjust things that are proprietary or can't be controlled due to version skew. So this is complicated, but naming is obviously a big part of assembling this. Discovery plays a part, especially in the beginning, but repository based naming is also needed because I want to bind more intuitive names like "Bose-sw-corner-livingroom" to my components such that if I blow out one speaker, I can replace it and not have the name I chose get thrown into the trash with the old speaker. This isn't really all that far off, or far out. Mike From d.sturek@att.net Mon Sep 10 07:17: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 D948D21F865B for ; Mon, 10 Sep 2012 07:17:17 -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 f8R2VfiN7hV7 for ; Mon, 10 Sep 2012 07:17:17 -0700 (PDT) Received: from nm19-vm0.bullet.mail.ac4.yahoo.com (nm19-vm0.bullet.mail.ac4.yahoo.com [98.139.53.212]) by ietfa.amsl.com (Postfix) with SMTP id 43ED621F8653 for ; Mon, 10 Sep 2012 07:17:17 -0700 (PDT) Received: from [98.139.52.193] by nm19.bullet.mail.ac4.yahoo.com with NNFMP; 10 Sep 2012 14:17:14 -0000 Received: from [66.94.237.103] by tm6.bullet.mail.ac4.yahoo.com with NNFMP; 10 Sep 2012 14:17:14 -0000 Received: from [127.0.0.1] by omp1008.access.mail.mud.yahoo.com with NNFMP; 10 Sep 2012 14:17:14 -0000 X-Yahoo-Newman-Id: 89793.97520.bm@omp1008.access.mail.mud.yahoo.com Received: (qmail 32657 invoked from network); 10 Sep 2012 14:17:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1347286634; bh=lGTNYcCb+yjbfDjGQECPmtcKUL2QuFPmUP0W1kA4DPw=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=m1Px4AATDrIuyLcQpCuO/AeleDqFm9aBGse8xaPLQZ1v244dUJAjvTPpgcheUo5d9mIJHzV+MsUU4pl75JKuxnQT9r/Y2W/1eF+wEYSAZctEH5KPR7GT2a+wjB7BzTTaaRZ/VHlmmUHXqrs7QDw5+g+Bu8DSQwhwstQ7YlNNqns= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: VbLibjMVM1kDlCBEK9OATrwFQEZWc6I84tFxiPAqOnfm2Xz TmTGIe_B9C.xffIB52ukaJMPzyeZDy564tPHDoQcZvT6fX7A4V.tU5ABtqD_ CpKmzFyTGZJSFlZ5LD4RxDn.4BJy6166XO515hWv7liSb97HE4ph4jfX.LYw _MsfwlXrHnHdDpamZRzuUx3FMNRVDgMk8ZPcNeVnCsDRWhoSItNnq7PmpMx_ aScX6.8M7Vhu26fta0vknNtsHXhNzw6yi5sSbJIWstvI5Yu4Iw3rsx_m1YQg 8iz9zdSnGINKpsnbZAJwLubPE44K_Mf6BWcAwfW_dt4A46.eL7P4YVT5dDqO PSc3Dj6nKeZ5yHdtDsFuuDT_kDSxnli6v_B9z5PULtQctzSLihSIPPyvUyQb ADkoegsKVi3uVEEs9WmBtm_QkTFQDbqrq.S.JQCINB4ql2KfEj7w- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [192.168.0.197] (d.sturek@69.105.138.252 with login) by smtp109.sbc.mail.mud.yahoo.com with SMTP; 10 Sep 2012 07:17:13 -0700 PDT User-Agent: Microsoft-MacOutlook/14.2.3.120616 Date: Mon, 10 Sep 2012 07:17:04 -0700 From: Don Sturek To: Brian E Carpenter , Ray Bellis Message-ID: Thread-Topic: [homenet] Unicast DNS within the Homenet? In-Reply-To: <504DF0F7.2050707@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Unicast DNS within the Homenet? 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, 10 Sep 2012 14:17:18 -0000 Bonjour is based on mDNS (http://datatracker.ietf.org/doc/draft-cheshire-dnsext-multicastdns/) and DNS-SD (http://datatracker.ietf.org/doc/draft-cheshire-dnsext-dns-sd/), both currently in the RFC editors queue..... Don On 9/10/12 6:53 AM, "Brian E Carpenter" wrote: >On 10/09/2012 14:09, Ray Bellis wrote: >> On 10 Sep 2012, at 13:58, Brian E Carpenter >> wrote: >> >>> Using literal addresses is evil for many reasons - surely we don't >>>need to >>> discuss that ancient question again? >> >> I wasn't promoting it, just noting that this is the current position, >>with Bonjour et al becoming the "preferred" way. The latter is "a good >>thing". > >afaik Bonjour is a proprietary protocol. How can that be a good thing? > >>> The right question is whether DNS is the appropriate solution for >>>converting >>> local devices names to addresses, or whether there is some other >>>naming service that >>> should be the standard. Since DNS is the IETF standard for converting >>>names >>> to addresses, there would need to be a pretty strong case for anything >>>else. >> >> The IETF has _other_ protocols for naming services (mDNS, LLMNR) that >>are designed for local networks, albeit with the "wrong" multicast scope >>as far as we're concerned. > >And SLP, explicitly designed for locating services. > >> My question is therefore more about whether (internal) unicast DNS is >>actually required at all. > >And I'm saying that's the wrong question. > >I think the right question is whether there is an *open* standard for >discovering >service addresses from service names that is more suitable than DNS. > > Brian > > >_______________________________________________ >homenet mailing list >homenet@ietf.org >https://www.ietf.org/mailman/listinfo/homenet From brian.e.carpenter@gmail.com Mon Sep 10 08:48: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 409CA21F8681 for ; Mon, 10 Sep 2012 08:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.636 X-Spam-Level: X-Spam-Status: No, score=-101.636 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, 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 vOlzQ2AOflNn for ; Mon, 10 Sep 2012 08:48:41 -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 8946121F865F for ; Mon, 10 Sep 2012 08:48:41 -0700 (PDT) Received: by eekb45 with SMTP id b45so1314329eek.31 for ; Mon, 10 Sep 2012 08:48:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=OQOk2x5/O0Jo6tgN+4GqfI1UUbCKVvEEOLNBBC8rRUg=; b=EZWeX5b1P1AsYb43YqlYwFo7Yhg3+vFskCvmO1LhWwUFbvUWVQnzuzoZFq+a4RZgby +5oEYpLQgWGZy7L8kEMscpxvTSkmZNR1KFr8uzhllV2jIYK+yOqDOfUIaraAeAMEqSmh JZOXjDtSzt3wg0mNmyy4L6yW9BquTeEZIhjKjCek6GvclBtz2XNissL3b9DQ0cQzvuFw uFwtj63VI2ZKJeZKptM460+Om1Zd+SntXXRezO68RKOioaoPLZHp320oCq/lfuJd9O2o j8RShS5jzhDkHpg/CkQwxuUy2JpsNhLP9zDMCSg6lth6Gh+bV4B9vN4y4/j5uuqbjR53 K24A== Received: by 10.14.204.72 with SMTP id g48mr20480053eeo.45.1347292120759; Mon, 10 Sep 2012 08:48:40 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-218-175.as13285.net. [2.102.218.175]) by mx.google.com with ESMTPS id v3sm39204634eep.10.2012.09.10.08.48.37 (version=SSLv3 cipher=OTHER); Mon, 10 Sep 2012 08:48:38 -0700 (PDT) Message-ID: <504E0BD6.5010200@gmail.com> Date: Mon, 10 Sep 2012 16:48:38 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Don Sturek References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Ray Bellis , "homenet@ietf.org Group" Subject: Re: [homenet] Unicast DNS within the Homenet? 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, 10 Sep 2012 15:48:42 -0000 Don, Yes, based on, and it will be good to see those RFCs out. What I'm basically worried about here is ending up with one toolset for homenets and a different toolset for small enterprise networks, which seem much more likely to go the DNS way than anything else. In practice there's no hard and fast boundary between home and small business. Brian On 10/09/2012 15:17, Don Sturek wrote: > Bonjour is based on mDNS > (http://datatracker.ietf.org/doc/draft-cheshire-dnsext-multicastdns/) and > DNS-SD (http://datatracker.ietf.org/doc/draft-cheshire-dnsext-dns-sd/), > both currently in the RFC editors queue..... > > Don > > On 9/10/12 6:53 AM, "Brian E Carpenter" > wrote: > >> On 10/09/2012 14:09, Ray Bellis wrote: >>> On 10 Sep 2012, at 13:58, Brian E Carpenter >>> wrote: >>> >>>> Using literal addresses is evil for many reasons - surely we don't >>>> need to >>>> discuss that ancient question again? >>> I wasn't promoting it, just noting that this is the current position, >>> with Bonjour et al becoming the "preferred" way. The latter is "a good >>> thing". >> afaik Bonjour is a proprietary protocol. How can that be a good thing? >> >>>> The right question is whether DNS is the appropriate solution for >>>> converting >>>> local devices names to addresses, or whether there is some other >>>> naming service that >>>> should be the standard. Since DNS is the IETF standard for converting >>>> names >>>> to addresses, there would need to be a pretty strong case for anything >>>> else. >>> The IETF has _other_ protocols for naming services (mDNS, LLMNR) that >>> are designed for local networks, albeit with the "wrong" multicast scope >>> as far as we're concerned. >> And SLP, explicitly designed for locating services. >> >>> My question is therefore more about whether (internal) unicast DNS is >>> actually required at all. >> And I'm saying that's the wrong question. >> >> I think the right question is whether there is an *open* standard for >> discovering >> service addresses from service names that is more suitable than DNS. >> >> Brian >> >> >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet > > > From brian.e.carpenter@gmail.com Mon Sep 10 08:55: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 9143E21F8707 for ; Mon, 10 Sep 2012 08:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.639 X-Spam-Level: X-Spam-Status: No, score=-101.639 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, 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 MDpzfcUjAyVx for ; Mon, 10 Sep 2012 08:55:44 -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 785FF21F8737 for ; Mon, 10 Sep 2012 08:55:44 -0700 (PDT) Received: by eaai11 with SMTP id i11so1000289eaa.31 for ; Mon, 10 Sep 2012 08:55: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 :subject:content-type:content-transfer-encoding; bh=3pKHgU6MBolpjnNeRKHCNZXYDQp0JcK4xfbE2K5jBKs=; b=knU7ww6RiHJIFM+t0TsqVLQLDfOPWuEgMNhIvTPPMe+cw1aNDf25NNwuXVdsCz+En3 ZvQJjHYvjNdH4Mn7PV8QgJYN5iDiAcx1h2bWVaO/BNTcZomNMzTOqLBw6xbjs+4V7boW bGIUEcDNHojPZJkQoaNjLRa6eWHGwBUjYzK3CEqjiODLxKteA38aAFOhHlWWTmztDyWB aPeB+wcZ8WRd8x2Qg1p0fXEKdLnlVbSYU3i7ul5K4O3yEbHYrEeYNgCkA+SdMLAR7WQT UN2jGBDYdGcyiPO1izNPgv9dR0RT+42cs7LGfXtkiMvtzt+xcl+oe/5RaFJib3/6l3bK 43Pg== Received: by 10.14.203.73 with SMTP id e49mr20441375eeo.27.1347292543730; Mon, 10 Sep 2012 08:55:43 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-218-175.as13285.net. [2.102.218.175]) by mx.google.com with ESMTPS id a7sm39242227eep.14.2012.09.10.08.55.42 (version=SSLv3 cipher=OTHER); Mon, 10 Sep 2012 08:55:42 -0700 (PDT) Message-ID: <504E0D7E.8000600@gmail.com> Date: Mon, 10 Sep 2012 16:55:42 +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=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [homenet] building a home theater 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, 10 Sep 2012 15:55:45 -0000 To be completely clear: -------- Original Message -------- Subject: building a home theater Date: Mon, 10 Sep 2012 07:13:40 -0700 From: Michael Thomas To: Brian E Carpenter CC: Ray Bellis , "homenet@ietf.org Group" References: <47437C06-FB3D-41AB-ADB9-01A4091640E1@nominet.org.uk> <504DE406.3050303@gmail.com> On 09/10/2012 05:58 AM, Brian E Carpenter wrote: COMMENT: Brian quoted this from Ray; Michael's MUA didn't add a second level of quotation > If it can be shown that Unicast DNS is only need for resolution of _external_ names then much of the discussion around _internal_ naming probably becomes moot. COMMENT: Brian said this: > The right question is whether DNS is the appropriate solution for converting > local devices names to addresses, or whether there is some other naming service that > should be the standard. Since DNS is the IETF standard for converting names > to addresses, there would need to be a pretty strong case for anything else. > > COMMENT: Michael said this: Maybe a thought experiment might help all of this along. In the very near future, I will probably be able to buy components and services like a display, an amp, anam/fm radio receiver, a cable/sat decoder, a jukebox-like disk server, speakers, lighting controls, internet based content services, and a popcorn popper. All IP enabled all wireless most likely. I want control these all from my phone, tablet or laptop where there the app brings all of these things together and wirelessly "wires" them all up much like banana plugs did before. I may want to have many different profiles of what constitutes a "theater" depending on whether I'm in the kitchen, on my lard-o-matic, or in a fully vegetative state on the couch. I need to be able to incrementally add components because I'm not rich, and I might want to add ad hoc components because my friends bring over some new gadget, or have content they'd like to source, etc. And I need to be able to have multiple different control points including possibly even allowing my friends to take control of the system as a whole. I generally want my app to control everything, but I am resigned to the fact that every once in a while I'm going to need to go to my speaker's web server and adjust things that are proprietary or can't be controlled due to version skew. So this is complicated, but naming is obviously a big part of assembling this. Discovery plays a part, especially in the beginning, but repository based naming is also needed because I want to bind more intuitive names like "Bose-sw-corner-livingroom" to my components such that if I blow out one speaker, I can replace it and not have the name I chose get thrown into the trash with the old speaker. This isn't really all that far off, or far out. Mike From d.sturek@att.net Mon Sep 10 08:57: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 480E421F850C for ; Mon, 10 Sep 2012 08:57:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 7VR1qdDJh47K for ; Mon, 10 Sep 2012 08:57:28 -0700 (PDT) Received: from nm8-vm3.bullet.mail.ne1.yahoo.com (nm8-vm3.bullet.mail.ne1.yahoo.com [98.138.91.138]) by ietfa.amsl.com (Postfix) with SMTP id 93E9721F84D6 for ; Mon, 10 Sep 2012 08:57:28 -0700 (PDT) Received: from [98.138.226.176] by nm8.bullet.mail.ne1.yahoo.com with NNFMP; 10 Sep 2012 15:57:25 -0000 Received: from [66.94.237.124] by tm11.bullet.mail.ne1.yahoo.com with NNFMP; 10 Sep 2012 15:57:25 -0000 Received: from [127.0.0.1] by omp1029.access.mail.mud.yahoo.com with NNFMP; 10 Sep 2012 15:57:25 -0000 X-Yahoo-Newman-Id: 285759.65145.bm@omp1029.access.mail.mud.yahoo.com Received: (qmail 23968 invoked from network); 10 Sep 2012 15:57:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1347292645; bh=dX4v4bge3mR53hEHme06xzLwJtqJ6HztWkV9M/Q2AN4=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=RxBt/iWgOoPQU6B5v7qO67BOkqNyWIfVIM+kZvUtQpXNuUqJjimXz4Ty13Lr9sV9oWIsOCKW0kd+fRMUzTDWn3vVmTausPLXsEm5N2a50z+u0G4cr2/jqDBmLHkgRxZwHwCfIDRpk+uE2GlcxWI+Baw4LDWVSMMhT4uF5fmO8aI= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: t8mFO7EVM1nKE8hFKVEiEBKKElY5tlyVk7QRU3wG4ewsa24 WhWO6fz8RbWH0TwJLmH2Uj5He43u4ACdbDP_DwYS3zHbH3sLkD7uyPDMWeny T0PLaK3lT5lYV203e0w.K9mm7hwHO9FcAnwLEbdiVR0244QhDUne6du1q3_M yOF0QXhhnwS9oWv5JbBb97AFS.zfc5RbPsWDdvCDu6kMgaoS4Rk9NaZVqfyi Zs7nF7550_u12Lf0A9xIROfnQ_McrPL_lm4pgKrPDLmMSIhRUQ7ituO3Y905 vJx9IZKm4zVvEETisSi1m3jZezPt0YSWmRiDdEl8F4Oigqar7OaW6OZub.kk i75XSwtaS3oKN2WTQxBaRTSfHoMDUjYBgjBXaQgfowHBa2IjRHQCg8ksyBNl bW_oMSl8xU3u1l6Shd8Fofp3PCjQ7JxinX1Vf9f9LYu8rbR5.9LJToKDll61 z3Lj9RQ1nVw-- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [192.168.0.197] (d.sturek@69.105.138.252 with login) by smtp107.sbc.mail.mud.yahoo.com with SMTP; 10 Sep 2012 08:57:24 -0700 PDT User-Agent: Microsoft-MacOutlook/14.2.3.120616 Date: Mon, 10 Sep 2012 08:57:14 -0700 From: Don Sturek To: Brian E Carpenter Message-ID: Thread-Topic: [homenet] Unicast DNS within the Homenet? In-Reply-To: <504E0BD6.5010200@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Ray Bellis , "homenet@ietf.org Group" Subject: Re: [homenet] Unicast DNS within the Homenet? 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, 10 Sep 2012 15:57:29 -0000 Hi Brian, Totally agree with you. In fact, I think Ray asked about the use case for unicast DNS within Homenet. I think locating service names in a small business, dormitory, etc. is that use case where mDNS does not scale well and where a globally unique name is maybe not necessary....... Don On 9/10/12 8:48 AM, "Brian E Carpenter" wrote: >Don, > >Yes, based on, and it will be good to see those RFCs out. > >What I'm basically worried about here is ending up with one >toolset for homenets and a different toolset for small enterprise >networks, which seem much more likely to go the DNS way than anything >else. In practice there's no hard and fast boundary between home and >small business. > > Brian > > >On 10/09/2012 15:17, Don Sturek wrote: >> Bonjour is based on mDNS >> (http://datatracker.ietf.org/doc/draft-cheshire-dnsext-multicastdns/) >>and >> DNS-SD (http://datatracker.ietf.org/doc/draft-cheshire-dnsext-dns-sd/), >> both currently in the RFC editors queue..... >> >> Don >> >> On 9/10/12 6:53 AM, "Brian E Carpenter" >> wrote: >> >>> On 10/09/2012 14:09, Ray Bellis wrote: >>>> On 10 Sep 2012, at 13:58, Brian E Carpenter >>>> wrote: >>>> >>>>> Using literal addresses is evil for many reasons - surely we don't >>>>> need to >>>>> discuss that ancient question again? >>>> I wasn't promoting it, just noting that this is the current position, >>>> with Bonjour et al becoming the "preferred" way. The latter is "a >>>>good >>>> thing". >>> afaik Bonjour is a proprietary protocol. How can that be a good thing? >>> >>>>> The right question is whether DNS is the appropriate solution for >>>>> converting >>>>> local devices names to addresses, or whether there is some other >>>>> naming service that >>>>> should be the standard. Since DNS is the IETF standard for converting >>>>> names >>>>> to addresses, there would need to be a pretty strong case for >>>>>anything >>>>> else. >>>> The IETF has _other_ protocols for naming services (mDNS, LLMNR) that >>>> are designed for local networks, albeit with the "wrong" multicast >>>>scope >>>> as far as we're concerned. >>> And SLP, explicitly designed for locating services. >>> >>>> My question is therefore more about whether (internal) unicast DNS is >>>> actually required at all. >>> And I'm saying that's the wrong question. >>> >>> I think the right question is whether there is an *open* standard for >>> discovering >>> service addresses from service names that is more suitable than DNS. >>> >>> Brian >>> >>> >>> _______________________________________________ >>> homenet mailing list >>> homenet@ietf.org >>> https://www.ietf.org/mailman/listinfo/homenet >> >> >> From v6ops@globis.net Mon Sep 10 09:14:56 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C034321F8740 for ; Mon, 10 Sep 2012 09:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 oyXnm3HfTSEw for ; Mon, 10 Sep 2012 09:14:56 -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 0679621F8735 for ; Mon, 10 Sep 2012 09:14:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id B89C68700E7; Mon, 10 Sep 2012 18:14:39 +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 ne6X1hvsM8Ke; Mon, 10 Sep 2012 18:14:11 +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 09E08870056; Mon, 10 Sep 2012 18:14:11 +0200 (CEST) Message-ID: <504E11CC.3080709@globis.net> Date: Mon, 10 Sep 2012 18:14:04 +0200 From: Ray Hunter User-Agent: Postbox 3.0.4 (Macintosh/20120616) MIME-Version: 1.0 To: Ray Bellis References: <47437C06-FB3D-41AB-ADB9-01A4091640E1@nominet.org.uk> <504DE406.3050303@gmail.com> <3C839850-3DAB-4797-91E4-9D036B70E158@nominet.org.uk> In-Reply-To: <3C839850-3DAB-4797-91E4-9D036B70E158@nominet.org.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Unicast DNS within the Homenet? 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, 10 Sep 2012 16:14:56 -0000 Ahem, who says Bonjour is becoming the "preferred" way? Last time I checked, I had to download and install additional (proprietary) software to use Bonjour, and it didn't work across a router. Multicast DNS has significant implications for power consumption for nodes that wish to sleep, and mandatory support for site-wide multicast would also make demands on Homenet routers e.g. PIM? MLD? Anyone claiming this is the preferred way should also have a good answer to those issues. regards RayH Ray Bellis wrote: > On 10 Sep 2012, at 13:58, Brian E Carpenter wrote: > >> Using literal addresses is evil for many reasons - surely we don't need to >> discuss that ancient question again? > > I wasn't promoting it, just noting that this is the current position, with Bonjour et al becoming the "preferred" way. The latter is "a good thing". > >> The right question is whether DNS is the appropriate solution for converting >> local devices names to addresses, or whether there is some other naming service that >> should be the standard. Since DNS is the IETF standard for converting names >> to addresses, there would need to be a pretty strong case for anything else. > > The IETF has _other_ protocols for naming services (mDNS, LLMNR) that are designed for local networks, albeit with the "wrong" multicast scope as far as we're concerned. > > My question is therefore more about whether (internal) unicast DNS is actually required at all. > > Ray > > From kerlyn2001@gmail.com Mon Sep 10 09:17: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 E1B5921F8442 for ; Mon, 10 Sep 2012 09:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 GnVdPXi3cWsv for ; Mon, 10 Sep 2012 09:17:32 -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 D1C8621F843E for ; Mon, 10 Sep 2012 09:17:31 -0700 (PDT) Received: by lbky2 with SMTP id y2so1441496lbk.31 for ; Mon, 10 Sep 2012 09:17:29 -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=ojS+X4ju3Ou2iFAkghPSaa/9hO8vulGQY4l+BT4g5IU=; b=AvQN7hi9QyRXL+IDwK/hlkxwkOzFWNLqE+/aselBbp6UZSzKUhmG4bgNryIgNxi0c7 g57ggcbiFB1iCVFYKzCUrYnkQXOoJYH0P7IcWZ4DY7cFDCtFWIDKYid31lfseq6VzHqs W1PNzyRX+YiyxjTf45LBkgPZabcNz8pQPnzmztxdVSkVSxhWvHairgtGuclNFH1gV4sE Kb1Bt/K6xoc0WjcA24Wd9CLbyVVp8z7Prymu7cw0hmPeB2AZp/PauTpEvE0IVsQTR7tA FjVIprPkH8ebkbmw7A0KvGHInfnjsfNsbDcnyzFxYlcsqzbANBq+fzf0YEBAf07rLApF JCGQ== MIME-Version: 1.0 Received: by 10.152.112.233 with SMTP id it9mr12835367lab.40.1347293849078; Mon, 10 Sep 2012 09:17:29 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.112.101.42 with HTTP; Mon, 10 Sep 2012 09:17:28 -0700 (PDT) In-Reply-To: <504E0BD6.5010200@gmail.com> References: <504E0BD6.5010200@gmail.com> Date: Mon, 10 Sep 2012 12:17:28 -0400 X-Google-Sender-Auth: F0on0qwSm3Trc029slPt2VNVv54 Message-ID: From: Kerry Lynn To: Brian E Carpenter Content-Type: text/plain; charset=ISO-8859-1 Cc: Ray Bellis , "homenet@ietf.org Group" , Don Sturek Subject: Re: [homenet] Unicast DNS within the Homenet? 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, 10 Sep 2012 16:17:33 -0000 What I'm concerned about is using one protocol for internal name resolution and another for external. Bonjour, mDNS and multicast DNS are synonymous. mDNS is based on DNS-SD, which is a conventional use of *existing* DNS RR types for service discovery. mDNS uses DNS-like messages. I'm OK with calling it "DNS-like" but to say that it is unrelated to DNS or a closed standard is just confusing the issues IMO. The Hamming distance between mDNS and DNS is virtually nil compared to other alternatives mentioned so far for internal name resolution (SLP, LLMNR, etc.) What this means in practice is that any resolver that deals with mDNS can also resolve global DNS names. I think that DNS and DNS-like protocols should be where we focus our limited time and energy for homenet naming use cases until someone comes up with a scenario that, by rough consensus, shows DNS to be unsuitable for homenet naming. Now back to Ray's original question, I can see a use for unicast mDNS resolution in homenet insofar as a previously cached binding might be validated with a unicast message. If that binding proves to be invalid, then the client could initiate a new discovery (using scoped multicast or some as yet TBD proxying scheme.) -K- On Mon, Sep 10, 2012 at 11:48 AM, Brian E Carpenter wrote: > Don, > > Yes, based on, and it will be good to see those RFCs out. > > What I'm basically worried about here is ending up with one > toolset for homenets and a different toolset for small enterprise > networks, which seem much more likely to go the DNS way than anything > else. In practice there's no hard and fast boundary between home and > small business. > > Brian > > > On 10/09/2012 15:17, Don Sturek wrote: >> Bonjour is based on mDNS >> (http://datatracker.ietf.org/doc/draft-cheshire-dnsext-multicastdns/) and >> DNS-SD (http://datatracker.ietf.org/doc/draft-cheshire-dnsext-dns-sd/), >> both currently in the RFC editors queue..... >> >> Don >> >> On 9/10/12 6:53 AM, "Brian E Carpenter" >> wrote: >> >>> On 10/09/2012 14:09, Ray Bellis wrote: >>>> On 10 Sep 2012, at 13:58, Brian E Carpenter >>>> wrote: >>>> >>>>> Using literal addresses is evil for many reasons - surely we don't >>>>> need to >>>>> discuss that ancient question again? >>>> I wasn't promoting it, just noting that this is the current position, >>>> with Bonjour et al becoming the "preferred" way. The latter is "a good >>>> thing". >>> afaik Bonjour is a proprietary protocol. How can that be a good thing? >>> >>>>> The right question is whether DNS is the appropriate solution for >>>>> converting >>>>> local devices names to addresses, or whether there is some other >>>>> naming service that >>>>> should be the standard. Since DNS is the IETF standard for converting >>>>> names >>>>> to addresses, there would need to be a pretty strong case for anything >>>>> else. >>>> The IETF has _other_ protocols for naming services (mDNS, LLMNR) that >>>> are designed for local networks, albeit with the "wrong" multicast scope >>>> as far as we're concerned. >>> And SLP, explicitly designed for locating services. >>> >>>> My question is therefore more about whether (internal) unicast DNS is >>>> actually required at all. >>> And I'm saying that's the wrong question. >>> >>> I think the right question is whether there is an *open* standard for >>> discovering >>> service addresses from service names that is more suitable than DNS. >>> >>> Brian >>> >>> >>> _______________________________________________ >>> homenet mailing list >>> homenet@ietf.org >>> https://www.ietf.org/mailman/listinfo/homenet >> >> >> > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From curtis@occnc.com Mon Sep 10 16:15: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 AC49321F8711 for ; Mon, 10 Sep 2012 16:15:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.6 X-Spam-Level: X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[AWL=-1.000, 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 LWTHxRQqvAwY for ; Mon, 10 Sep 2012 16:15:21 -0700 (PDT) Received: from gateway1.orleans.occnc.com (gateway1.orleans.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id A718D21F8702 for ; Mon, 10 Sep 2012 16:15:21 -0700 (PDT) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id q8ANFJQg013320; Mon, 10 Sep 2012 19:15:19 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201209102315.q8ANFJQg013320@gateway1.orleans.occnc.com> To: Ray Bellis From: Curtis Villamizar In-reply-to: Your message of "Mon, 10 Sep 2012 12:34:21 -0000." <47437C06-FB3D-41AB-ADB9-01A4091640E1@nominet.org.uk> Date: Mon, 10 Sep 2012 19:15:18 -0400 Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Unicast DNS within the Homenet? X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 23:15:22 -0000 In message <47437C06-FB3D-41AB-ADB9-01A4091640E1@nominet.org.uk> Ray Bellis writes: > An interesting question has come up during the Arch Doc team's > discussions around naming and service discovery: > > "What in-home services actually require Unicast DNS lookup?" [*] > > The one obvious case is in-home web servers (i.e. CPE configuration) > although a prior posting suggested that most people just use an IPv4 > address (e.g. 192.168.1.1) rather than a DNS name for that. Many > devices now support Bonjour for that. > > If it can be shown that Unicast DNS is only need for resolution of > _external_ names then much of the discussion around _internal_ naming > probably becomes moot. > > thanks, > > Ray > > [*] I'm specifically _not_ talking about normal recursive DNS for > global DNS names. Ray, I've read the thread so far and I'm replying to the original message. The app that needs DNS is anything from outside or from a mobile device that requires access to the home without going through a cloud intermediary (usually not free). PC to PC SIP is one example, optionally with video. The most common intermediary is skype. There are also numerous SIP providers that essentially broker the initial connection for free (handle the SIP part, not the RTP part) and only charge if you connect to the PSTN where they are usually a SIP back to back UI connection and incur a fee from the PSTN. There is no reason why SIP URLs could not be used with IPv6. Admittedly, not a popular idea with the phone companies. For IPv4 today the cloud intermediary is a necessary evil due to both side being behind a NAT and having no means to get a DNS name for themselves. With IPv6 this can be solved. With IPv6 if we get it right you won't need to go through a third party to change your thermostat because you just found out that you are coming home early - you can directly address your thermostat by name (hopefully with reasonable authentication). At issue is whether the homenet WG is going to continue with PC world business as usual, which is lame discovery protocols that work only when there is only one subnet and are useless otherwise. One argument for multiple subnets is that bridging the GbE segment to the WiFi segment can swamp the WiFi segment. By routing between the two, active queue management (QoS) is easier and all of the segment broadcast and multicast on the GbE segment need not appear on the wireless. There are other motivations such as having an open guest wireless channel vs having a secure wireless channel, plus a wired segment. WiFi home routers able to support two channels are not uncommon today, though they are on the high end of home stuff (available on the shelves of you consumer and office supply places). It is better not to bridge the guest and secure segments together but rather to route between them. With IPv6 and the prospect of GUA for everything, the practice of hiding horribly insecure devices and protocols behind a firewall needs to disappear. It has proven unsafe over and over in enterprise of any size, where one compromise exposes the entire private side. If it is not DNS, it has to meet some requirements: 1. work over multiple subnets 2. tie into DNS if devices are to be accessed from elsewhere If it is DNS, it has to meet some requirement that DNS as practiced isn't very good at right now. 1. there needs to be a means of creating a namespace without going to a registry first (entirely local, but provider delegation would be better) 2. a usable interface is needed to assign names to devices (dyndns is almost adequate, setting host name on each device, but better would be to assign names centrally - configured dhcp entries) In either case where multiple routers are encountered, some means to resolve who is in charge of the name space is needed. Or we can continue with yet another lame half-baked solution de-jour for a single subnet home carrying forward the thinking of NATed PI addresses behind a firewall and have a different set of solutions for soho, small business, and up. Regarding some of the other comments. ... I see the point about the home with wireless audio and video components. There is only so much that can be done in a dorm or other high density housing (apartments) where having many WiFi APs crowd the channel space. Even where I live, where lots are 1.5-2.5 acres, I saw today 6 APs, three on channel 6, when I looked at my wife's laptop to see why it was having a bad day. This is why many dorms have wired Ethernet, and that tried to go all wireless and switched back. The campus library, the dorm lounges, etc still have wireless. Due to virus and worm problems MAC addresses need to be registered with campus IT before a student device is granted access. Only very public places like lounges and library have open wireless and are somewhat isolated (untrusted guest treatment). Of course students can still bring in wireless routers and NAT and make a mess of things (and do). ... Brian, I agree that two namespaces is evil (or whatever you called it). I also agree that if it is not DNS there needs to be a very good reason. Curtis From jhw@apple.com Mon Sep 10 18:42:00 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA40321F86F9 for ; Mon, 10 Sep 2012 18:42:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZtfGrmKKDTl for ; Mon, 10 Sep 2012 18:42:00 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id CDC2321F86F6 for ; Mon, 10 Sep 2012 18:41:59 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay13.apple.com ([17.128.113.29]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPS id <0MA5008FNWPLDVS2@mail-out.apple.com> for homenet@ietf.org; Mon, 10 Sep 2012 18:41:50 -0700 (PDT) X-AuditID: 1180711d-b7f1c6d000001a44-ef-504e96def470 Received: from chive.apple.com (chive.apple.com [17.128.115.15]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay13.apple.com (Apple SCV relay) with SMTP id 39.02.06724.ED69E405; Mon, 10 Sep 2012 18:41:50 -0700 (PDT) Received: from kallisti.apple.com ([17.193.13.64]) by chive.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MA50070NWPQAP30@chive.apple.com> for homenet@ietf.org; Mon, 10 Sep 2012 18:41:50 -0700 (PDT) From: james woodyatt In-reply-to: <47437C06-FB3D-41AB-ADB9-01A4091640E1@nominet.org.uk> Date: Mon, 10 Sep 2012 18:41:49 -0700 Message-id: <9466256C-546F-4EEE-9F94-CBF0C4E5967C@apple.com> References: <47437C06-FB3D-41AB-ADB9-01A4091640E1@nominet.org.uk> To: "homenet@ietf.org Group" X-Mailer: Apple Mail (2.1604) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNLMWRmVeSWpSXmKPExsUi2FDMr3tvml+AQe8RZYv3iw6xODB6LFny kymAMYrLJiU1J7MstUjfLoEr4+iCuYwFu3kr5nyZxNzA+IKri5GTQ0LARKJ5yT9mCFtM4sK9 9WxdjFwcQgITmCRmvr3JAuFMY5KYdmw6I0gVs4CWxPqdx5lAbF4BPYm/36aCdQsLmEns/9vO BmKzCahIfLt8F6yGU8BJ4s78K2BxFgFVieb9h9kh5mhLPHl3gRVijo3E2jXvwOJCAo4S1+5M BbNFBPQlnh75xQZxnazExUMX2Ccw8s9CcsYsJGfMQjJ2ASPzKkbBotScxEpDY73EgoKcVL3k /NxNjOAgK5Tdwbj/J/8hRgEORiUe3hdyfgFCrIllxZW5hxglOJiVRHiXlwCFeFMSK6tSi/Lj i0pzUosPMUpzsCiJ8041AUoJpCeWpGanphakFsFkmTg4pRoYuVZN9zi7RPXZ1JduO2Zc4//k a5g52Xlea+oV26Tv+5aKWrTfE0hI3rV1knt6xO0p8fk1cTN7z6efvhrHHH3Lvth64/TUOeuD F17XjLUM/yt5pilIxTw73sH9upUKf67HWjHvtIa/qY5Ke2oYb8+r4Kg68mx5env5RPdHf4uy q7JurGlnvn1UiaU4I9FQi7moOBEAfEVO6C4CAAA= Subject: Re: [homenet] Unicast DNS within the Homenet? 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, 11 Sep 2012 01:42:01 -0000 On Sep 10, 2012, at 05:34 , Ray Bellis wrote: > > An interesting question has come up during the Arch Doc team's discussions around naming and service discovery: > > "What in-home services actually require Unicast DNS lookup?" [*] Really? How has the architecture team managed to overlook the obvious problem that homenets with interior routing domains comprising multiple networks cannot use either mDNS or LLMNR, which are confined to link-local multicast scope, without requiring name service proxies? As Brian notes, you could try to resurrect SLP, but-- really? I don't see that happening. Name service proxies also sound like a major undertaking compared to ordinary unicast DNS. What an exciting distributed database scheme with which consider securing its integrity... I can't wait. Alternatively, you could try to extend mDNS and/or LLMNR to support a wider multicast scope, then require routed homenets to implement some kind of multicast routing protocol. That sounds like a big specification effort and I'm not sanguine about the chances for adoption there. Finally, we could punt on the homenet routing problem, and just use mDNS+DNS-SD exclusively-- I'm sure I can think of at least one major player in the home networking space that would be quite happy to see such an outcome turn out to be the status quo, but last I checked, this working group didn't like that idea very much. So, um-- I guess the answer to the Arch Doc team's question should be, "NAME ALL THE THINGS IN DNS!!" What am I missing? -- james woodyatt member of technical staff, core os networking From joelja@bogus.com Mon Sep 10 20:58:09 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 336C221F875C for ; Mon, 10 Sep 2012 20:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 htnLP1gNVylk for ; Mon, 10 Sep 2012 20:58:08 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id C1EE421F866D for ; Mon, 10 Sep 2012 20:58:08 -0700 (PDT) Received: from joels-MacBook-Air.local (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q8B3w4gJ050919 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 11 Sep 2012 03:58:05 GMT (envelope-from joelja@bogus.com) Message-ID: <504EB6CB.2090503@bogus.com> Date: Mon, 10 Sep 2012 20:58:03 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120821 Thunderbird/15.0 MIME-Version: 1.0 To: james woodyatt References: <47437C06-FB3D-41AB-ADB9-01A4091640E1@nominet.org.uk> <9466256C-546F-4EEE-9F94-CBF0C4E5967C@apple.com> In-Reply-To: <9466256C-546F-4EEE-9F94-CBF0C4E5967C@apple.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Tue, 11 Sep 2012 03:58:06 +0000 (UTC) Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Unicast DNS within the Homenet? 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, 11 Sep 2012 03:58:09 -0000 On 9/10/12 6:41 PM, james woodyatt wrote: > On Sep 10, 2012, at 05:34 , Ray Bellis wrote: >> An interesting question has come up during the Arch Doc team's discussions around naming and service discovery: >> >> "What in-home services actually require Unicast DNS lookup?" [*] > Finally, we could punt on the homenet routing problem, and just use mDNS+DNS-SD exclusively-- I'm sure I can think of at least one major player in the home networking space that would be quite happy to see such an outcome turn out to be the status quo, but last I checked, this working group didn't like that idea very much. > > So, um-- I guess the answer to the Arch Doc team's question should be, "NAME ALL THE THINGS IN DNS!!" What am I missing? > I tend to agree that you can't just punt on the DNS for the same reason you can't just punt on routing in the absence of either you're left needing some topological abomination to knit together the home-nets. From Ray.Bellis@nominet.org.uk Tue Sep 11 00:04: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 1F7DE21F8741 for ; Tue, 11 Sep 2012 00:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, 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 9rZgm6bi1jD2 for ; Tue, 11 Sep 2012 00:04:35 -0700 (PDT) Received: from mx3.nominet.org.uk (mail.nominet.org.uk [213.248.199.23]) by ietfa.amsl.com (Postfix) with ESMTP id A5CCC21F8742 for ; Tue, 11 Sep 2012 00:04:34 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:Content-Type: MIME-Version; b=yV12R7dJtDMSKuLqVFx+0lP7SV4L8vfVb9EBP00T4X36IreuS/2HuxUB a3TJfFEfoYBcXaLi/YF0v0FLHyOgkW2Vkx/MrhkmcdVG30oMHHL/DD6Hs cAUHF4JjfAtl9SD; 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=1347347075; x=1378883075; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20Re:=20[homenet]=20Unicast=20DNS=20within=20th e=20Homenet?|Date:=20Tue,=2011=20Sep=202012=2007:04:43=20 +0000|Message-ID:=20<7AEA434B-240B-487D-B132-E9817FF9080D @nominet.org.uk>|To:=20Benjamin=20Kerensa=20|CC:=20"homenet@ietf.org=20Group"=20|MIME-Version:=201.0|In-Reply-To:=20 |References:=20<47437C06-FB3D-41AB-ADB9-01A4091640E1@nomi net.org.uk>=0D=0A=20; bh=pmVlZj9WFkwNQnYd+UzRI7N363QHG3mVUjYNmcn3SwY=; b=n7NOQWCBx96ovk/dSU1IbLhCVuG7ph9y080f15QmdQjZvri3woMETEXS 4qUCJ7DWxy9epVZU9G/0eWOp419xdIpw6LARNLOpikXQZSwvT6dUaM0fA T2sje1EzYx2KqxV; X-IronPort-AV: E=Sophos;i="4.80,403,1344207600"; d="scan'208,217";a="43112754" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx3.nominet.org.uk with ESMTP; 11 Sep 2012 08:04:33 +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, 11 Sep 2012 08:04:32 +0100 From: Ray Bellis To: Benjamin Kerensa Thread-Topic: [homenet] Unicast DNS within the Homenet? Thread-Index: AQHNj9WGEmxE0srBiEixzKcLTByNEZeEpwGA Date: Tue, 11 Sep 2012 07:04:43 +0000 Message-ID: <7AEA434B-240B-487D-B132-E9817FF9080D@nominet.org.uk> References: <47437C06-FB3D-41AB-ADB9-01A4091640E1@nominet.org.uk> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7AEA434B240B487DB132E9817FF9080Dnominetorguk_" MIME-Version: 1.0 Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Unicast DNS within the Homenet? 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, 11 Sep 2012 07:04:37 -0000 --_000_7AEA434B240B487DB132E9817FF9080Dnominetorguk_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On 11 Sep 2012, at 05:25, Benjamin Kerensa > wrote: Correct. 192.168.1.1 is also the most common default router IPv4 address. Many devices now support Bonjour for that ... What about "localhost" I've never yet seen a system that couldn't resolve localhost all by itself. Ray --_000_7AEA434B240B487DB132E9817FF9080Dnominetorguk_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
On 11 Sep 2012, at 05= :25, Benjamin Kerensa <bkerensa@gm= ail.com>
 wrote:

<= p>Correct. 192.168.1.1 is also the most common default router IPv4 address.=

Many devices now support Bonjour for that

...

What about "localhost"

I've never yet seen a system that couldn't re= solve localhost all by itself.

Ray

<= /div>
= --_000_7AEA434B240B487DB132E9817FF9080Dnominetorguk_-- From Ray.Bellis@nominet.org.uk Tue Sep 11 00:19: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 A7B2821F8594 for ; Tue, 11 Sep 2012 00:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 ims+hf+yI6OO for ; Tue, 11 Sep 2012 00:19:36 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by ietfa.amsl.com (Postfix) with ESMTP id 980E821F8587 for ; Tue, 11 Sep 2012 00:19:35 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:Content-Type: Content-ID:Content-Transfer-Encoding:MIME-Version; b=0X2nz88dac7++VK/zb9RFD1Q20N5RK1bkU2W0M07xXFuQqEP8JfRC0UZ Oj7Rg0KeJdt/BTz0eXXg/mbPVS8PFQcOKh1RmtacoygikteYoH2Nhu/mL gILtyHa9zcEZ3/k; 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=1347347976; x=1378883976; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20Re:=20[homenet]=20Unicast=20DNS=20within=20th e=20Homenet?|Date:=20Tue,=2011=20Sep=202012=2007:19:46=20 +0000|Message-ID:=20|To:=20james=20woodyatt=20 |CC:=20"homenet@ietf.org=20Group"=20 |MIME-Version:=201.0|Content-Transfer-Encoding:=20quoted- printable|Content-ID:=20|In-Reply-To:=20<9466256C-546F-4EEE-9F94-CBF0C4E5967 C@apple.com>|References:=20<47437C06-FB3D-41AB-ADB9-01A40 91640E1@nominet.org.uk>=0D=0A=20<9466256C-546F-4EEE-9F94- CBF0C4E5967C@apple.com>; bh=1rs077KOs09d3m3X6198K8XFe7Wo6yWnl901C2MXVDs=; b=VBxlUnNghFMONiRYQ7ZDrBP13STxADhsRsDmXoosxv5hCKc5tpswycT3 DSFxTYR/zl8QeWo5LX6HshC2QpLr+3USHeC3VVdlQenYRFLwRioqpmYR1 jy33HEnzZ7L90na; X-IronPort-AV: E=Sophos;i="4.80,403,1344207600"; d="scan'208";a="35491434" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx4.nominet.org.uk with ESMTP; 11 Sep 2012 08:19:34 +0100 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%19]) with mapi; Tue, 11 Sep 2012 08:19:34 +0100 From: Ray Bellis To: james woodyatt Thread-Topic: [homenet] Unicast DNS within the Homenet? Thread-Index: AQHNj76o9swfV7GkUUytb/Tfeogo8JeEq2MA Date: Tue, 11 Sep 2012 07:19:46 +0000 Message-ID: References: <47437C06-FB3D-41AB-ADB9-01A4091640E1@nominet.org.uk> <9466256C-546F-4EEE-9F94-CBF0C4E5967C@apple.com> In-Reply-To: <9466256C-546F-4EEE-9F94-CBF0C4E5967C@apple.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Unicast DNS within the Homenet? 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, 11 Sep 2012 07:19:37 -0000 On 11 Sep 2012, at 02:41, james woodyatt wrote: > Really? How has the architecture team managed to overlook the obvious pr= oblem that homenets with interior routing domains comprising multiple netwo= rks cannot use either mDNS or LLMNR, which are confined to link-local multi= cast scope, without requiring name service proxies? >=20 > As Brian notes, you could try to resurrect SLP, but-- really? I don't se= e that happening. Name service proxies also sound like a major undertaking= compared to ordinary unicast DNS. What an exciting distributed database s= cheme with which consider securing its integrity... I can't wait. I'm informed that mDNS proxying is already understood and present in severa= l devices. > Alternatively, you could try to extend mDNS and/or LLMNR to support a wid= er multicast scope, then require routed homenets to implement some kind of = multicast routing protocol. That sounds like a big specification effort an= d I'm not sanguine about the chances for adoption there. Either of the two above is assumed, with the arch team tending towards prox= ying rather than extending multicast. The final recommendation would be pa= rt of a "solutions-draft", and not in the "architecture". > Finally, we could punt on the homenet routing problem, and just use mDNS+= DNS-SD exclusively-- I'm sure I can think of at least one major player in t= he home networking space that would be quite happy to see such an outcome t= urn out to be the status quo, but last I checked, this working group didn't= like that idea very much. >=20 > So, um-- I guess the answer to the Arch Doc team's question should be, "N= AME ALL THE THINGS IN DNS!!" What am I missing? I shall attempt to clarify. Iff all "in-home" services can be reached (whilst in-home) by mDNS-like pro= tocols then we do not need an "in-home" unicast DNS zone. To reach those same services from _outside_ the home does of course need th= em to exist in the global DNS, as pointed out by Curtis. To do that we need (I think) only two things: 1. the ability for the device (or the network on its behalf) to register a= FQDN for that device. 2. the ability for clients of that device to learn that FQDN when it's boo= kmarked so that they can reach it from outside. In the absence of an internal Unicast DNS zone all of the discussion of wha= t that zone should be is irrelevant. No need for "ULA prefix-based" LQDNs,= for example. So the point of the original email was to test that first assumption - i.e.= what services don't (or can't) work in-home without a local unicast DNS zo= ne. Ray From brian.e.carpenter@gmail.com Tue Sep 11 02:17: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 DA72C21F876E for ; Tue, 11 Sep 2012 02:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 OCGBOjSORSdC for ; Tue, 11 Sep 2012 02:17:15 -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 2ADFB21F85AC for ; Tue, 11 Sep 2012 02:17:15 -0700 (PDT) Received: by eaai11 with SMTP id i11so149389eaa.31 for ; Tue, 11 Sep 2012 02:17:14 -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=zPT03MHJmSoO4sPuPTe8JrpwYEFT+4Xp2+th3ByWR64=; b=iIMgxdWMWvkw+GXIX82FEVnMMrPAI5DbwJSLs13AqsL49ICwPZNf8Un6ZYPYy2BWT2 k4omjWJhXnFfFfeIs2r+OA+TNJlIWt4tKiRvqWzbgKqowCzJApoMelHeJ7W9aIp6BTBX YXqgMTpwjJuiX5QX7YU9+5t9WOSzmDE4/5+jre/Hqh7xZZiDCh5rbA6q/q88TgCTzCyR oxHMDcDuBpSa799a0oxwEaaUdZ4Hr0WcejJCXyDb3rRlCPeuMnukDZOWu5FSHz/+IbKa RO/dFPQ4RqUuKHXfWK4E0UzYvH4+ifCEafJtSxzisVZM+a4n+P3/+yJ4GuPBewkbFRDn 8l5Q== Received: by 10.14.204.200 with SMTP id h48mr24664945eeo.7.1347355034270; Tue, 11 Sep 2012 02:17:14 -0700 (PDT) Received: from [128.232.110.207] (c207.al.cl.cam.ac.uk. [128.232.110.207]) by mx.google.com with ESMTPS id h2sm45342254eeo.3.2012.09.11.02.17.12 (version=SSLv3 cipher=OTHER); Tue, 11 Sep 2012 02:17:13 -0700 (PDT) Message-ID: <504F019B.9090101@gmail.com> Date: Tue, 11 Sep 2012 10:17:15 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ray Bellis References: <47437C06-FB3D-41AB-ADB9-01A4091640E1@nominet.org.uk> <9466256C-546F-4EEE-9F94-CBF0C4E5967C@apple.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "homenet@ietf.org Group" , james woodyatt Subject: Re: [homenet] Unicast DNS within the Homenet? 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, 11 Sep 2012 09:17:16 -0000 On 11/09/2012 08:19, Ray Bellis wrote: ... > So the point of the original email was to test that first assumption - i.e. what services don't (or can't) work in-home without a local unicast DNS zone. Excuse my ignorance, but if a LAN has both mDNS and DNS available, what happens when an app calls getnameinfo() ? Brian From simon.perreault@viagenie.ca Tue Sep 11 06:11:20 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ABA521F880E for ; Tue, 11 Sep 2012 06:11:20 -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.043, 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 m-6rw8tQKUfv for ; Tue, 11 Sep 2012 06:11:20 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE8321F86B1 for ; Tue, 11 Sep 2012 06:11:19 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:1d7c:5db4:d43e:122c]) by jazz.viagenie.ca (Postfix) with ESMTPSA id B1100415B1 for ; Tue, 11 Sep 2012 09:11:18 -0400 (EDT) Message-ID: <504F3876.2030100@viagenie.ca> Date: Tue, 11 Sep 2012 09:11:18 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120828 Thunderbird/15.0 MIME-Version: 1.0 To: homenet@ietf.org References: <47437C06-FB3D-41AB-ADB9-01A4091640E1@nominet.org.uk> <9466256C-546F-4EEE-9F94-CBF0C4E5967C@apple.com> <504F019B.9090101@gmail.com> In-Reply-To: <504F019B.9090101@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [homenet] Unicast DNS within the Homenet? 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, 11 Sep 2012 13:11:20 -0000 Le 2012-09-11 05:17, Brian E Carpenter a écrit : > Excuse my ignorance, but if a LAN has both mDNS and DNS available, > what happens when an app calls getnameinfo() ? Current situation is: "implementation-dependant". In fact, getnameinfo() is not defined in terms of DNS. It can use any underlying naming service, or even multiple ones. On Linux this is configured with /etc/nsswitch.conf. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From brian.e.carpenter@gmail.com Tue Sep 11 06:45: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 4C70321F87D0 for ; Tue, 11 Sep 2012 06:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 dFz2XzIviDsG for ; Tue, 11 Sep 2012 06:45:12 -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 389D521F87D2 for ; Tue, 11 Sep 2012 06:45:12 -0700 (PDT) Received: by eekb45 with SMTP id b45so466446eek.31 for ; Tue, 11 Sep 2012 06:45:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=iUWLeDhCdkdxOwy1gOZq7WPAQVWp92g1/pYn87toYN4=; b=A4qD8D0s/6gvQcyft8lfS4V4PfPd2NQHHkljbHX4KLMIDlnh7yk/NJe9yynwU7MWzv cPaMhq5+lMI5wO6n1rBJndgGirxVu5FP7/3amyhJTx9zTiyJXPPqVnsA625nlSwZUyhf rQUKN747fWELYsv1IFW44fkXJPeXFTOXcIoBNxbHJzBHBjTO8vnhKmhg6PdQmhMY3d/T yiJB3f7Oks+oa+KSvgU9ReJ1z7T4zU241/Ved8ALGH8hoWdM9P5GfNhrKHU/8yNfbooH QJvA4TR++vrdezB5wxFgcSweRIQchSUeKRwQJmRfltWzjpzfWeGXvUGE9+oe/LyhIOGX eQ8Q== Received: by 10.14.202.71 with SMTP id c47mr25919892eeo.42.1347371111370; Tue, 11 Sep 2012 06:45:11 -0700 (PDT) Received: from [128.232.110.207] (c207.al.cl.cam.ac.uk. [128.232.110.207]) by mx.google.com with ESMTPS id r45sm47259008eem.6.2012.09.11.06.45.08 (version=SSLv3 cipher=OTHER); Tue, 11 Sep 2012 06:45:10 -0700 (PDT) Message-ID: <504F4068.8050205@gmail.com> Date: Tue, 11 Sep 2012 14:45:12 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Simon Perreault References: <47437C06-FB3D-41AB-ADB9-01A4091640E1@nominet.org.uk> <9466256C-546F-4EEE-9F94-CBF0C4E5967C@apple.com> <504F019B.9090101@gmail.com> <504F3876.2030100@viagenie.ca> In-Reply-To: <504F3876.2030100@viagenie.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: homenet@ietf.org Subject: Re: [homenet] Unicast DNS within the Homenet? 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, 11 Sep 2012 13:45:13 -0000 On 11/09/2012 14:11, Simon Perreault wrote: > Le 2012-09-11 05:17, Brian E Carpenter a =C3=A9crit : >> Excuse my ignorance, but if a LAN has both mDNS and DNS available, >> what happens when an app calls getnameinfo() ? >=20 > Current situation is: "implementation-dependant". >=20 > In fact, getnameinfo() is not defined in terms of DNS. It can use any > underlying naming service, or even multiple ones. On Linux this is > configured with /etc/nsswitch.conf. Thanks. Then it seems to me that a recommendation about the desirable beh= aviour of getnameinfo() and getaddrinfo() needs to be made, consistent with the = final recommendation for mDNS vs DNS. At least we should describe a consistent deployment scenario. Brian From mike@mtcc.com Tue Sep 11 06:52: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 B855621F87E9 for ; Tue, 11 Sep 2012 06:52:22 -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 8mGaNiB+p84Y for ; Tue, 11 Sep 2012 06:52:22 -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 93D3A21F84AF for ; Tue, 11 Sep 2012 06:52:21 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id q8BDqG0l029668 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 11 Sep 2012 06:52:17 -0700 Message-ID: <504F4210.9040700@mtcc.com> Date: Tue, 11 Sep 2012 06:52:16 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Ray Bellis References: <47437C06-FB3D-41AB-ADB9-01A4091640E1@nominet.org.uk> <9466256C-546F-4EEE-9F94-CBF0C4E5967C@apple.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1626; t=1347371540; x=1348235540; 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]=20Unicast=20DNS=20within=20th e=20Homenet? |Sender:=20 |To:=20Ray=20Bellis=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=+/he4MrSInd9019ZYLtC379lt79VYArqDsK8Xk+8Rt8=; b=lnIu+BHJ1FtxcN7VQMGSTXmmk5FRgoMgWv4AF0GUSBmPvzLQ3OR5ZQWz7Q ZfWNINijo3p738gFRcBz2yTOocK+s8ptUiUyR553RhSFPkxq+vzbjqr85Ncx FoWeZHjBI6d3+7wAiDO0kNmWcf6Hl9UvA6Gr7m/a3JA3aLY3jt33o=; 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" , james woodyatt Subject: Re: [homenet] Unicast DNS within the Homenet? 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, 11 Sep 2012 13:52:23 -0000 On 09/11/2012 12:19 AM, Ray Bellis wrote: > I shall attempt to clarify. > > Iff all "in-home" services can be reached (whilst in-home) by mDNS-like protocols then we do not need an "in-home" unicast DNS zone. > > To reach those same services from _outside_ the home does of course need them to exist in the global DNS, as pointed out by Curtis. > > To do that we need (I think) only two things: > > 1. the ability for the device (or the network on its behalf) to register a FQDN for that device. > > 2. the ability for clients of that device to learn that FQDN when it's bookmarked so that they can reach it from outside. > > In the absence of an internal Unicast DNS zone all of the discussion of what that zone should be is irrelevant. No need for "ULA prefix-based" LQDNs, for example. > > So the point of the original email was to test that first assumption - i.e. what services don't (or can't) work in-home without a local unicast DNS zone. > I'm sorry but this formulation is just plain wrong on almost every level. Zeroconf-ish like solutions are when you *can't* do anything better. DNS is better when you can. If I take the time to (re-)name something, I want that to end up in a repository whose destiny is not tied to the particular device. I very often want that name/device to be accessible outside of my home too. So no, let's not start from an assumption that it's an mDNS world in the home. I'd say let's start from the opposite assumption that it's a normal DNS world inside the home where mDNS is a way to auto-populate a DNS repository in lieu of anything better. Mike From mellon@fugue.com Tue Sep 11 07:00:20 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A533821F87CB for ; Tue, 11 Sep 2012 07:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jqT5YJEqTGAs for ; Tue, 11 Sep 2012 07:00:19 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 2785A21F8798 for ; Tue, 11 Sep 2012 07:00:16 -0700 (PDT) Received: from kali.lan (c-174-62-144-132.hsd1.nh.comcast.net [174.62.144.132]) by toccata.fugue.com (Postfix) with ESMTPSA id 5309823802A7; Tue, 11 Sep 2012 10:00:14 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Ted Lemon In-Reply-To: <504F4210.9040700@mtcc.com> Date: Tue, 11 Sep 2012 10:00:11 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0EBBAAF8-CF07-45B8-897C-C4CC69CC57F7@fugue.com> References: <47437C06-FB3D-41AB-ADB9-01A4091640E1@nominet.org.uk> <9466256C-546F-4EEE-9F94-CBF0C4E5967C@apple.com> <504F4210.9040700@mtcc.com> To: Michael Thomas X-Mailer: Apple Mail (2.1486) Cc: Ray Bellis , "homenet@ietf.org Group" , james woodyatt Subject: Re: [homenet] Unicast DNS within the Homenet? 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, 11 Sep 2012 14:00:20 -0000 On Sep 11, 2012, at 9:52 AM, Michael Thomas wrote: > So no, let's not start from an assumption that it's an mDNS world in = the > home. I'd say let's start from the opposite assumption that it's a = normal > DNS world inside the home where mDNS is a way to auto-populate a > DNS repository in lieu of anything better. +1. I've begun to feel as if the discussion going on here is leading to a = product I don't want, so I haven't felt like it was worth weighing in on = this subject, but this pretty much represents my feelings about it as = well. From ajs@anvilwalrusden.com Tue Sep 11 07:59:20 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B37F21F8802 for ; Tue, 11 Sep 2012 07:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.592 X-Spam-Level: X-Spam-Status: No, score=-0.592 tagged_above=-999 required=5 tests=[AWL=0.248, 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 aVK50+3+xzel for ; Tue, 11 Sep 2012 07:59:20 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 210DD21F87FE for ; Tue, 11 Sep 2012 07:59:20 -0700 (PDT) Received: from mx1.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 545048A031 for ; Tue, 11 Sep 2012 14:59:18 +0000 (UTC) Date: Tue, 11 Sep 2012 10:59:29 -0400 From: Andrew Sullivan To: homenet@ietf.org Message-ID: <20120911145928.GC20895@mx1.yitter.info> References: <47437C06-FB3D-41AB-ADB9-01A4091640E1@nominet.org.uk> <9466256C-546F-4EEE-9F94-CBF0C4E5967C@apple.com> <504F019B.9090101@gmail.com> <504F3876.2030100@viagenie.ca> <504F4068.8050205@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <504F4068.8050205@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [homenet] Unicast DNS within the Homenet? 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, 11 Sep 2012 14:59:20 -0000 On Tue, Sep 11, 2012 at 02:45:12PM +0100, Brian E Carpenter wrote: > Thanks. Then it seems to me that a recommendation about the desirable behaviour > of getnameinfo() and getaddrinfo() needs to be made, consistent with the final > recommendation for mDNS vs DNS. At least we should describe a consistent > deployment scenario. But you can't _make_ such a recommendation, because different scenarios -- network-topologically indistinguishable from one another -- require very different conclusions. This is exactly the same problem MIF faced with the DNS server selection logic. You naturally want to use the DNS server that you believe is going to provide you with the right answers. But when you move networks (say, into the coffeeshop which is using Stupid DNS Tricks to authenticate you as a customer first), you actually need the _least good_ answer sometimes, in order to move you from your expensive mobile radio onto your cheap wifi. The same problem crops up here. Inside your house, mDNS is perhaps the right answer. But for bookmarking on your laptop that you carry on the road but want to use with your home network then, it's exactly the wrong answer. So this once again comes down to use cases, and trading userland functionality against complications that make the specification complex, and implementations tricky and therefore buggy. To moan just a little bit, this is why many of us think that the mutliple namespace approaches (seen in mDNS, llmnr, before those NetBIOS, and so on) are harmful. Inevitably, these systems get hooked up to the wider Internet, and the inconsistencies thereby revealed make people confused. (This isn't to say there is an obvious better answer, given the facts of the world about DNS name registration and resolution.) Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From kerlyn2001@gmail.com Tue Sep 11 08:17: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 9A5EA21F8810 for ; Tue, 11 Sep 2012 08:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 4KiceFtudD5s for ; Tue, 11 Sep 2012 08:17:06 -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 99D6221F87FF for ; Tue, 11 Sep 2012 08:17:05 -0700 (PDT) Received: by lbky2 with SMTP id y2so513344lbk.31 for ; Tue, 11 Sep 2012 08:17:04 -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=OcT35n13kL9aBhEUYRmcCugvcHcy2sBlXxcFVLahnvE=; b=a+IqRcDYkADbM93cPeQh8DW3uNYYNtvSVPxhQLkYD8bKTS0jx8gJ1czGFQlYjhm1ej vaIlT7zLJNgBJBFTAKAPzCRh4dMjTlIrPmwXEpZZtBByUMFHLKYv5C3Pp3Pr/4vViJI2 Cx5O/35XGIwm4Hncts9joNLbhIddQ9AsEQCRB2uc6lIYIjy1hhMeM4IiM8Pxm2n49RAB f7D86E7ZvN3c68+AViMp2zSpR1sWPJcjt7G0VKKtanymfeWEjNiA+rEqBu3u3J8rMw2P SbUeHuKK5wpkavXQt4H8yhmFYVdGUHesbZ7WJtLcBYoRWZ9jYv3/ZN5qC9jIq0plLpHc SsbQ== MIME-Version: 1.0 Received: by 10.112.82.130 with SMTP id i2mr6258101lby.126.1347376624388; Tue, 11 Sep 2012 08:17:04 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.112.101.42 with HTTP; Tue, 11 Sep 2012 08:17:04 -0700 (PDT) In-Reply-To: <0EBBAAF8-CF07-45B8-897C-C4CC69CC57F7@fugue.com> References: <47437C06-FB3D-41AB-ADB9-01A4091640E1@nominet.org.uk> <9466256C-546F-4EEE-9F94-CBF0C4E5967C@apple.com> <504F4210.9040700@mtcc.com> <0EBBAAF8-CF07-45B8-897C-C4CC69CC57F7@fugue.com> Date: Tue, 11 Sep 2012 11:17:04 -0400 X-Google-Sender-Auth: xc9WKUz-4O_mkpln7TizNOvhtUk Message-ID: From: Kerry Lynn To: Ted Lemon Content-Type: text/plain; charset=ISO-8859-1 Cc: Ray Bellis , "homenet@ietf.org Group" , Michael Thomas , james woodyatt Subject: Re: [homenet] Unicast DNS within the Homenet? 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, 11 Sep 2012 15:17:06 -0000 On Tue, Sep 11, 2012 at 10:00 AM, Ted Lemon wrote: > On Sep 11, 2012, at 9:52 AM, Michael Thomas wrote: >> So no, let's not start from an assumption that it's an mDNS world in the >> home. I'd say let's start from the opposite assumption that it's a normal >> DNS world inside the home where mDNS is a way to auto-populate a >> DNS repository in lieu of anything better. > > +1. > > I've begun to feel as if the discussion going on here is leading to a product I don't want, so I haven't felt like it was worth weighing in on this subject, but this pretty much represents my feelings about it as well. > Can we explore how this auto-population might occur? It seems that to glean bindings from mDNS or LLMNR there would have to be at least (or exactly?) one "agent" per subnet. The natural place for the agent to reside is on the router. Presumably each agent learns the address of the DNS server via stateless DHCPv6. The DNS server would need to be configured with a TSIG for each agent. The agent hears multicast responses to lookups on its local link, then periodically updates the DNS server. I assume an alternative would be to auto-configure via stateful DHCPv6. Would that more or less of a configuration burden than the sketch above? Would work with existing devices? Thanks, -K- > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From mellon@fugue.com Tue Sep 11 09:01: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 4D56B21F849A for ; Tue, 11 Sep 2012 09:01:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_25=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 E1N-CpJX-dSh for ; Tue, 11 Sep 2012 09:01:58 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id E19CA21F8498 for ; Tue, 11 Sep 2012 09:01:58 -0700 (PDT) Received: from [192.168.1.133] (c-174-62-144-132.hsd1.nh.comcast.net [174.62.144.132]) by toccata.fugue.com (Postfix) with ESMTPSA id CE4F62380621; Tue, 11 Sep 2012 12:01:54 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Ted Lemon In-Reply-To: Date: Tue, 11 Sep 2012 12:01:53 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <47437C06-FB3D-41AB-ADB9-01A4091640E1@nominet.org.uk> <9466256C-546F-4EEE-9F94-CBF0C4E5967C@apple.com> <504F4210.9040700@mtcc.com> <0EBBAAF8-CF07-45B8-897C-C4CC69CC57F7@fugue.com> To: Kerry Lynn X-Mailer: Apple Mail (2.1486) Cc: Ray Bellis , "homenet@ietf.org Group" , Michael Thomas , james woodyatt Subject: Re: [homenet] Unicast DNS within the Homenet? 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, 11 Sep 2012 16:01:59 -0000 On Sep 11, 2012, at 11:17 AM, Kerry Lynn wrote: > Can we explore how this auto-population might occur? It seems that to > glean bindings from mDNS or LLMNR there would have to be at least > (or exactly?) one "agent" per subnet. The natural place for the agent = to > reside is on the router. Presumably each agent learns the address of > the DNS server via stateless DHCPv6. The DNS server would need to > be configured with a TSIG for each agent. The agent hears multicast > responses to lookups on its local link, then periodically updates the > DNS server. >=20 > I assume an alternative would be to auto-configure via stateful = DHCPv6. > Would that more or less of a configuration burden than the sketch = above? > Would work with existing devices? There are a couple of options being pursued in the DHC working group; = the DHCP address registration process would be an obvious mechanism for = leveraging DHCP to populate the DNS. The idea here is that you do = RA+SLAAC, or RA+CGA, and then you contact the DHCP server to tell it = what address you allocated and what name you want associated with it, = and to get any local network configuration information you might need. However, of course this is new technology that isn't even standardized = yet. I'd like it if homenet recommended implementing this, but I think = another way of populating the DNS is through mDNS=97when a host = publishes its name in mDNS, it's assumed to be valid as long as no = conflicting registration has been made locally. I don't particularly = love this method because mDNS doesn't have the same duplicate detection = features that DHCP does through the DUID, but it wouldn't be _worse_ = than plain mDNS, and would allow the DNS resolver to query a consistent = FQDN tree for local names, so that it would work whether you were = attached to the local wire or not. From brian.e.carpenter@gmail.com Tue Sep 11 09:16: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 E9D5D21F86B2 for ; Tue, 11 Sep 2012 09:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.646 X-Spam-Level: X-Spam-Status: No, score=-101.646 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, 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 DHfeuP4cU4J6 for ; Tue, 11 Sep 2012 09:16:40 -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 3FF6021F8535 for ; Tue, 11 Sep 2012 09:16:39 -0700 (PDT) Received: by eaai11 with SMTP id i11so385470eaa.31 for ; Tue, 11 Sep 2012 09:16:36 -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=AhrHeCQZpQ0i0wbub9YoBBS7VrBXJWFJu39WIz2DscQ=; b=LPJ8uLDciWdkzAoH2bUyVOXPyTSRTxyKUK8h2aithb2auCQvZHGJZ1iOK3ZweuWw8r a05sduWotVLyi5wNCctfxtsprE5Vs4c/ZQSjBMeCHTXIpZNPw3p/NY1GW6SrK0wrWZTh QvAvYVL2Oyp5jPorR7HsW1Uzjw5dfolQzQzr9K+gUx1bvQ2sf+Nw876JKYvmFriDELkw zt0IMdiA7yBuj8LE2AP0IKMp4UwKs6pQLg4JY5/TvkpFyNRggHcP9eeN4n/sxSdHvYEp ZVVYe0HPI88zUUoS5Ga8lSE7qXstu1TjQ+VbNFywbFCW0U8bH9DlVPDbvekpPgNj6kz+ JX8w== Received: by 10.14.205.6 with SMTP id i6mr26348159eeo.13.1347380196378; Tue, 11 Sep 2012 09:16:36 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-219-157.as13285.net. [2.102.219.157]) by mx.google.com with ESMTPS id h42sm48386587eem.5.2012.09.11.09.16.34 (version=SSLv3 cipher=OTHER); Tue, 11 Sep 2012 09:16:35 -0700 (PDT) Message-ID: <504F63E6.2050306@gmail.com> Date: Tue, 11 Sep 2012 17:16:38 +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: <47437C06-FB3D-41AB-ADB9-01A4091640E1@nominet.org.uk> <9466256C-546F-4EEE-9F94-CBF0C4E5967C@apple.com> <504F019B.9090101@gmail.com> <504F3876.2030100@viagenie.ca> <504F4068.8050205@gmail.com> <20120911145928.GC20895@mx1.yitter.info> In-Reply-To: <20120911145928.GC20895@mx1.yitter.info> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org Subject: Re: [homenet] Unicast DNS within the Homenet? 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, 11 Sep 2012 16:16:41 -0000 On 11/09/2012 15:59, Andrew Sullivan wrote: > On Tue, Sep 11, 2012 at 02:45:12PM +0100, Brian E Carpenter wrote: >> Thanks. Then it seems to me that a recommendation about the desirable behaviour >> of getnameinfo() and getaddrinfo() needs to be made, consistent with the final >> recommendation for mDNS vs DNS. At least we should describe a consistent >> deployment scenario. > > But you can't _make_ such a recommendation, because different > scenarios -- network-topologically indistinguishable from one another > -- require very different conclusions. Surely we can recommend, or at least suggest, that the library which provides getnameinfo() tries both mDNS and DNS and returns the results in a configurable order. And if we can't do that, surely we can describe scenarios and their consequences. As Fred, I think, said the app is going to have to do something happy-eyeballs like but we can help it along the way. Brian > This is exactly the same problem MIF faced with the DNS server > selection logic. You naturally want to use the DNS server that you > believe is going to provide you with the right answers. But when you > move networks (say, into the coffeeshop which is using Stupid DNS > Tricks to authenticate you as a customer first), you actually need the > _least good_ answer sometimes, in order to move you from your > expensive mobile radio onto your cheap wifi. > > The same problem crops up here. Inside your house, mDNS is perhaps > the right answer. But for bookmarking on your laptop that you carry > on the road but want to use with your home network then, it's exactly > the wrong answer. So this once again comes down to use cases, and > trading userland functionality against complications that make the > specification complex, and implementations tricky and therefore buggy. > > To moan just a little bit, this is why many of us think that the > mutliple namespace approaches (seen in mDNS, llmnr, before those > NetBIOS, and so on) are harmful. Inevitably, these systems get hooked > up to the wider Internet, and the inconsistencies thereby revealed > make people confused. (This isn't to say there is an obvious better > answer, given the facts of the world about DNS name registration and > resolution.) > > Best, > > A > From mike@mtcc.com Tue Sep 11 09:24:56 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 127CF21F85A8 for ; Tue, 11 Sep 2012 09:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_25=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 1RP6Noepvard for ; Tue, 11 Sep 2012 09:24:55 -0700 (PDT) Received: from mtcc.com (mtcc.com [IPv6:2001:5a8:4:9fe0:224:8cff:feaa:6d9b]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6B621F8535 for ; Tue, 11 Sep 2012 09:24:55 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id q8BGOdrW019839 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 11 Sep 2012 09:24:39 -0700 Message-ID: <504F65C7.4010501@mtcc.com> Date: Tue, 11 Sep 2012 09:24:39 -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: <47437C06-FB3D-41AB-ADB9-01A4091640E1@nominet.org.uk> <9466256C-546F-4EEE-9F94-CBF0C4E5967C@apple.com> <504F4210.9040700@mtcc.com> <0EBBAAF8-CF07-45B8-897C-C4CC69CC57F7@fugue.com> 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=1808; t=1347380680; x=1348244680; 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]=20Unicast=20DNS=20within=20th e=20Homenet? |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=gvdHSaO7yVmGQoahe8FjIc2Un/9jO1zsW8gFwKmXzcY=; b=sl4B4L8+s1c6IZGvpH2rmCYi2hKWthH8P3EVsLXEY9hYUG9VA3hXXy8GF5 NlfXhuOHuDSB3biSn7ArF6kNOimt9zYEYuwI8IACZeCtzwobTFQFrWsJ6pDa vwUvMHER2NBrzpv1nPbddK81aam5mESxotBZqmZAac4A0XAiswC54=; 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 Bellis , Kerry Lynn , "homenet@ietf.org Group" , james woodyatt Subject: Re: [homenet] Unicast DNS within the Homenet? 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, 11 Sep 2012 16:24:56 -0000 On 09/11/2012 09:01 AM, Ted Lemon wrote: > There are a couple of options being pursued in the DHC working group; the DHCP address registration process would be an obvious mechanism for leveraging DHCP to populate the DNS. The idea here is that you do RA+SLAAC, or RA+CGA, and then you contact the DHCP server to tell it what address you allocated and what name you want associated with it, and to get any local network configuration information you might need. Maybe somebody can educated me, but isn't it a bit dangerous to use an auto-configured address as a way to contact a host? If I change out my ethernet hardware, for example, my auto-conf address would normally change too, right? > > However, of course this is new technology that isn't even standardized yet. I'd like it if homenet recommended implementing this, but I think another way of populating the DNS is through mDNS—when a host publishes its name in mDNS, it's assumed to be valid as long as no conflicting registration has been made locally. I don't particularly love this method because mDNS doesn't have the same duplicate detection features that DHCP does through the DUID, but it wouldn't be _worse_ than plain mDNS, and would allow the DNS resolver to query a consistent FQDN tree for local names, so that it would work whether you were attached to the local wire or not. > DHCP may be a solution but it ought not be the only solution, right? What if there's no relationship between my dns repository and the DHCP server? That is, suppose that Google hosted my DNS and thus wasn't actually on my home network. I suppose that a home router could work in concert by either working with its DHCP or listening to mdns chatter and then doing IXFR's to a name server. Is that what's being talked about? Mike From mellon@fugue.com Tue Sep 11 09:37: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 DC38421F84D3 for ; Tue, 11 Sep 2012 09:37:34 -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] 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 a1ZFFAHY83xd for ; Tue, 11 Sep 2012 09:37:34 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id C2CBD21F84CD for ; Tue, 11 Sep 2012 09:37:33 -0700 (PDT) Received: from [192.168.1.133] (c-174-62-144-132.hsd1.nh.comcast.net [174.62.144.132]) by toccata.fugue.com (Postfix) with ESMTPSA id 9B0832380621; Tue, 11 Sep 2012 12:37:31 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Ted Lemon In-Reply-To: <504F65C7.4010501@mtcc.com> Date: Tue, 11 Sep 2012 12:37:30 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <47437C06-FB3D-41AB-ADB9-01A4091640E1@nominet.org.uk> <9466256C-546F-4EEE-9F94-CBF0C4E5967C@apple.com> <504F4210.9040700@mtcc.com> <0EBBAAF8-CF07-45B8-897C-C4CC69CC57F7@fugue.com> <504F65C7.4010501@mtcc.com> To: Michael Thomas X-Mailer: Apple Mail (2.1486) Cc: Ray Bellis , Kerry Lynn , "homenet@ietf.org Group" , james woodyatt Subject: Re: [homenet] Unicast DNS within the Homenet? 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, 11 Sep 2012 16:37:35 -0000 On Sep 11, 2012, at 12:24 PM, Michael Thomas wrote: > Maybe somebody can educated me, but isn't it a bit dangerous to use > an auto-configured address as a way to contact a host? If I change out = my > ethernet hardware, for example, my auto-conf address would normally > change too, right? No. Things change. All that's required to deal with this is that the = underlying protocol support it. The DHCP DUID identification system = does support this kind of change, as long as the actual device doesn't = change. If the device changes, then when the registration expires, the = name can be reclaimed. > DHCP may be a solution but it ought not be the only solution, right? = What if > there's no relationship between my dns repository and the DHCP server? = That > is, suppose that Google hosted my DNS and thus wasn't actually on my = home > network. I suppose that a home router could work in concert by either = working > with its DHCP or listening to mdns chatter and then doing IXFR's to a = name > server. Is that what's being talked about? If there is no relationship between the home gateway, which is the DHCP = server in the case I'm describing, and the DNS server, then this can't = work whether the protocol used for getting names is mDNS or DHCP or some = third protocol we haven't talked about yet. From each@isc.org Tue Sep 11 10:45: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 515C321F87E2 for ; Tue, 11 Sep 2012 10:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-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 dYPLqU6+2Np9 for ; Tue, 11 Sep 2012 10:45:03 -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 BFC9621F87A8 for ; Tue, 11 Sep 2012 10:45:03 -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 84D6B5F98A6; Tue, 11 Sep 2012 17:44:53 +0000 (UTC) (envelope-from each@isc.org) Received: by bikeshed.isc.org (Postfix, from userid 10292) id 7A3D4216C6F; Tue, 11 Sep 2012 17:44:51 +0000 (UTC) Date: Tue, 11 Sep 2012 17:44:51 +0000 From: Evan Hunt To: Michael Thomas Message-ID: <20120911174451.GC15012@isc.org> References: <47437C06-FB3D-41AB-ADB9-01A4091640E1@nominet.org.uk> <9466256C-546F-4EEE-9F94-CBF0C4E5967C@apple.com> <504F4210.9040700@mtcc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <504F4210.9040700@mtcc.com> User-Agent: Mutt/1.4.2.3i Cc: Ray Bellis , "homenet@ietf.org Group" , james woodyatt Subject: Re: [homenet] Unicast DNS within the Homenet? 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, 11 Sep 2012 17:45:04 -0000 On Tue, Sep 11, 2012 at 06:52:16AM -0700, Michael Thomas wrote: > So no, let's not start from an assumption that it's an mDNS world in the > home. I'd say let's start from the opposite assumption that it's a normal > DNS world inside the home where mDNS is a way to auto-populate a > DNS repository in lieu of anything better. Another +1. -- Evan Hunt -- each@isc.org Internet Systems Consortium, Inc. From each@isc.org Tue Sep 11 11:07: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 422EB21F8585 for ; Tue, 11 Sep 2012 11:07:55 -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 z-wedYL5r+Wm for ; Tue, 11 Sep 2012 11:07:54 -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 5553521F8584 for ; Tue, 11 Sep 2012 11:07:54 -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 BFB3F5F9925; Tue, 11 Sep 2012 18:07:45 +0000 (UTC) (envelope-from each@isc.org) Received: by bikeshed.isc.org (Postfix, from userid 10292) id DDFDA216C6E; Tue, 11 Sep 2012 18:07:43 +0000 (UTC) Date: Tue, 11 Sep 2012 18:07:43 +0000 From: Evan Hunt To: Ted Lemon Message-ID: <20120911180743.GD15012@isc.org> References: <47437C06-FB3D-41AB-ADB9-01A4091640E1@nominet.org.uk> <9466256C-546F-4EEE-9F94-CBF0C4E5967C@apple.com> <504F4210.9040700@mtcc.com> <0EBBAAF8-CF07-45B8-897C-C4CC69CC57F7@fugue.com> <504F65C7.4010501@mtcc.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: Ray Bellis , Kerry Lynn , Michael Thomas , "homenet@ietf.org Group" , james woodyatt Subject: Re: [homenet] Unicast DNS within the Homenet? 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, 11 Sep 2012 18:07:55 -0000 On Tue, Sep 11, 2012 at 12:37:30PM -0400, Ted Lemon wrote: > No. Things change. All that's required to deal with this is that the > underlying protocol support it. The DHCP DUID identification system > does support this kind of change, as long as the actual device doesn't > change. If the device changes, then when the registration expires, the > name can be reclaimed. This does raise a point, though: Dynamic DNS doesn't have an expiration mechanism. Populating the DNS using mDNS is a good idea, I think, but it might be nice if we had some method of signaling the intended future disposation of a name. I'm thinking along the lines of a new rrtype, or maybe just a TXT record, that can indicate things like "after time T, it's okay to delete this rrset", or "if this name already exists with a different address, it's okay to replace the old one instead of adding to it". My home zone is cluttered up with the names of a couple of dozen laptops and ipods belonging to neighbors and visitors over the past year. It's probably my own fault for misconfiguring DHCP (I don't think it's doing the right thing in the "on expiry" block, and it hasn't been a high priority for me to fix it). But if we're going to be supplying DNS data from multiple sources -- DHCP, mDNS, maybe others -- then it might be a good idea to manage time limits on the demand side. -- Evan Hunt -- each@isc.org Internet Systems Consortium, Inc. From jhw@apple.com Tue Sep 11 11:30:32 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D56E21F862A for ; Tue, 11 Sep 2012 11:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vEl5hhCwz4OB for ; Tue, 11 Sep 2012 11:30:31 -0700 (PDT) Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id D9DC421F8608 for ; Tue, 11 Sep 2012 11:30:31 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay15.apple.com ([17.128.113.54]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MA7001AG7DF0070@mail-out.apple.com> for homenet@ietf.org; Tue, 11 Sep 2012 11:29:55 -0700 (PDT) X-AuditID: 11807136-b7fb36d000003396-b0-504f8323ec3b Received: from spicerack.apple.com (spicerack.apple.com [17.128.115.40]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay15.apple.com (Apple SCV relay) with SMTP id 18.4C.13206.3238F405; Tue, 11 Sep 2012 11:29:55 -0700 (PDT) Received: from kallisti.apple.com ([17.193.13.64]) by spicerack.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MA7003F57DOWZ20@spicerack.apple.com> for homenet@ietf.org; Tue, 11 Sep 2012 11:29:54 -0700 (PDT) From: james woodyatt In-reply-to: <20120911180743.GD15012@isc.org> Date: Tue, 11 Sep 2012 11:29:48 -0700 Message-id: References: <47437C06-FB3D-41AB-ADB9-01A4091640E1@nominet.org.uk> <9466256C-546F-4EEE-9F94-CBF0C4E5967C@apple.com> <504F4210.9040700@mtcc.com> <0EBBAAF8-CF07-45B8-897C-C4CC69CC57F7@fugue.com> <504F65C7.4010501@mtcc.com> <20120911180743.GD15012@isc.org> To: Evan Hunt X-Mailer: Apple Mail (2.1604) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGLMWRmVeSWpSXmKPExsUi2FCsoavc7B9gsP6oiMX7RYdYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsWAfd8EXtopXN3ewNTCeYe1i5OSQEDCRWDWzhR3CFpO4cG89 WxcjF4eQwAwmiYXLZoEVCQnMY5I4vrcWxGYW0JJYv/M4E4jNK6An8ffbVGYQW1jATGL/33Y2 EJtNQEXi2+W7YDWcAroSvX1NYDUsAqoSC493s0PM0Zfo3fOQDcLWlnjy7gIrxEwbicMPFkAd 8ZxZoulnB1hCREBG4uHk5VCXykpcPHSBfQKjwCwkN81CctMsJHMXMDKvYhQsSs1JrDQ01Uss KMhJ1UvOz93ECA69QrMdjDv+yh1iFOBgVOLhTcz0DxBiTSwrrsw9xCjBwawkwptuBRTiTUms rEotyo8vKs1JLT7EKM3BoiTOO8PEL0BIID2xJDU7NbUgtQgmy8TBKdXAuLT1rrMOh5bUHu/d TCUsDclpqrNjvzVXvdkc4yy488VMlqfRv0MlvnTkFlXN48wXW/Lg24b2vYJ3zv/pOC/l/Y0z doLE5LerWN0CYpZL3IrOktuYf1L8XWJr7dbS4NoVlx7PWy6QsP+h35vGC08fRUz72+He8XxZ 6pwPi14u3tvkl7GhNb43RomlOCPRUIu5qDgRAF68ccI5AgAA Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Unicast DNS within the Homenet? 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, 11 Sep 2012 18:30:32 -0000 On Sep 11, 2012, at 11:07 , Evan Hunt wrote: > > This does raise a point, though: Dynamic DNS doesn't have an expiration mechanism. [...] My home zone is cluttered up with the names of a couple of dozen laptops and ipods belonging to neighbors and visitors over the past year. [...] I recommend reading section 5 of "Understanding Apple's Back-to-My-Mac Service" [RFC 6281], which gives a brief summary of how this problem is effectively and reliably managed in that system. There you will find references to the following truly under-loved technical specifications: Maybe HOMENET could push for these to be taken up as IETF work items? -- james woodyatt member of technical staff, core os networking From each@isc.org Tue Sep 11 11:46: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 87D1121F865E for ; Tue, 11 Sep 2012 11:46:52 -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 WMsZJEttzPJo for ; Tue, 11 Sep 2012 11:46:52 -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 D401521F8658 for ; Tue, 11 Sep 2012 11:46:51 -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 465DDC9496; Tue, 11 Sep 2012 18:46:44 +0000 (UTC) (envelope-from each@isc.org) Received: by bikeshed.isc.org (Postfix, from userid 10292) id 36223216C6E; Tue, 11 Sep 2012 18:46:44 +0000 (UTC) Date: Tue, 11 Sep 2012 18:46:44 +0000 From: Evan Hunt To: james woodyatt Message-ID: <20120911184644.GA18577@isc.org> References: <9466256C-546F-4EEE-9F94-CBF0C4E5967C@apple.com> <504F4210.9040700@mtcc.com> <0EBBAAF8-CF07-45B8-897C-C4CC69CC57F7@fugue.com> <504F65C7.4010501@mtcc.com> <20120911180743.GD15012@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] Unicast DNS within the Homenet? 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, 11 Sep 2012 18:46:52 -0000 > I recommend reading section 5 of "Understanding Apple's Back-to-My-Mac Service" [RFC > 6281], which gives a brief summary of how this problem is effectively and reliably > managed in that system. There you will find references to the following truly > under-loved technical specifications: > > > > > Maybe HOMENET could push for these to be taken up as IETF work items? Thanks for the pointer. I'm not sure about long lived queries, but update leases is clearly useful, and I would support resurrecting it. -- Evan Hunt -- each@isc.org Internet Systems Consortium, Inc. From mike@mtcc.com Tue Sep 11 13:08: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 90CEE21F86B3 for ; Tue, 11 Sep 2012 13:08:05 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ky1-W5HfsYUO for ; Tue, 11 Sep 2012 13:08:04 -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 9792121F86AF for ; Tue, 11 Sep 2012 13:07:54 -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 q8BK7dZY032081 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 11 Sep 2012 13:07:40 -0700 Message-ID: <504F9A0B.1080604@mtcc.com> Date: Tue, 11 Sep 2012 13:07:39 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Evan Hunt References: <47437C06-FB3D-41AB-ADB9-01A4091640E1@nominet.org.uk> <9466256C-546F-4EEE-9F94-CBF0C4E5967C@apple.com> <504F4210.9040700@mtcc.com> <0EBBAAF8-CF07-45B8-897C-C4CC69CC57F7@fugue.com> <504F65C7.4010501@mtcc.com> <20120911180743.GD15012@isc.org> In-Reply-To: <20120911180743.GD15012@isc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1262; t=1347394064; x=1348258064; 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]=20Unicast=20DNS=20within=20th e=20Homenet? |Sender:=20 |To:=20Evan=20Hunt=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=Sm8oIFYDOqWofaWXvkb4l9fqJt3kaQtCbGUO3i7svZM=; b=D/JCpBkP12FLD7PLHnn+DbyL4Hy6CPJavhwi6ygaiCyOUK2SCPFABlUoO3 r2L2nIiLH3ey+02hZaW8AyIm30FU83eH7p0UbI+sX4L8wE51X79BP9C/MKJO 1vKBhPo1FQDPPz7xwGou5uqnlLd7UOfsWIW6WpEITNI1NlYyvTAJ4=; 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 Bellis , Kerry Lynn , Ted Lemon , "homenet@ietf.org Group" , james woodyatt Subject: Re: [homenet] Unicast DNS within the Homenet? 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, 11 Sep 2012 20:08:05 -0000 On 09/11/2012 11:07 AM, Evan Hunt wrote: > My home zone is cluttered up with the names of a couple of dozen laptops and ipods belonging to neighbors and visitors over the past year. It's probably my own fault for misconfiguring DHCP (I don't think it's doing the right thing in the "on expiry" block, and it hasn't been a high priority for me to fix it). But if we're going to be supplying DNS data from multiple sources -- DHCP, mDNS, maybe others -- then it might be a good idea to manage time limits on the demand side. A more fundamental question is enrollment. Security considerations are usually the sworn enemy of zeroconf like solutions. How we make those tradeoffs will most likely be a difficult conversation. What gives something on my home network the right to announce itself, offer services, change state in some repository, etc, etc? If we're using the property that they need to have access to my home wifi as proof the device is "mine" rather than "somebody else's", then lets stop right now with the posture that what we're doing is "zeroconf" because configuring a wifi password is most certainly not "zeroconf". Which brings me to: we shouldn't be hung up with "zeroconf", we should be shooting for "littleconf". Mike From mellon@fugue.com Tue Sep 11 13:26:20 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F53621F86B0 for ; Tue, 11 Sep 2012 13:26:20 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SPbj7qUQbgv3 for ; Tue, 11 Sep 2012 13:26:19 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id C4CF021F86AF for ; Tue, 11 Sep 2012 13:26:19 -0700 (PDT) Received: from kali.lan (c-174-62-144-132.hsd1.nh.comcast.net [174.62.144.132]) by toccata.fugue.com (Postfix) with ESMTPSA id 200D923802A7; Tue, 11 Sep 2012 16:26:16 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Ted Lemon In-Reply-To: <504F9A0B.1080604@mtcc.com> Date: Tue, 11 Sep 2012 16:26:07 -0400 Content-Transfer-Encoding: 7bit Message-Id: <2FF4E6A5-CB01-4992-8CC6-1720023E2AD9@fugue.com> References: <47437C06-FB3D-41AB-ADB9-01A4091640E1@nominet.org.uk> <9466256C-546F-4EEE-9F94-CBF0C4E5967C@apple.com> <504F4210.9040700@mtcc.com> <0EBBAAF8-CF07-45B8-897C-C4CC69CC57F7@fugue.com> <504F65C7.4010501@mtcc.com> <20120911180743.GD15012@isc.org> <504F9A0B.1080604@mtcc.com> To: Michael Thomas X-Mailer: Apple Mail (2.1486) Cc: Evan Hunt , Ray Bellis , Kerry Lynn , "homenet@ietf.org Group" , james woodyatt Subject: Re: [homenet] Unicast DNS within the Homenet? 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, 11 Sep 2012 20:26:20 -0000 On Sep 11, 2012, at 4:07 PM, Michael Thomas wrote: > Which brings me to: we shouldn't be hung up with "zeroconf", we should > be shooting for "littleconf". Yup. From curtis@occnc.com Tue Sep 11 13:57: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 2202221F8646 for ; Tue, 11 Sep 2012 13:57:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.933 X-Spam-Level: X-Spam-Status: No, score=-2.933 tagged_above=-999 required=5 tests=[AWL=-0.333, 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 W2KEjfxcyym8 for ; Tue, 11 Sep 2012 13:57:16 -0700 (PDT) Received: from gateway1.orleans.occnc.com (gateway1.orleans.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 2BED621F85A3 for ; Tue, 11 Sep 2012 13:57:15 -0700 (PDT) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id q8BKv8dN025351; Tue, 11 Sep 2012 16:57:11 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201209112057.q8BKv8dN025351@gateway1.orleans.occnc.com> To: Andrew Sullivan From: Curtis Villamizar In-reply-to: Your message of "Tue, 11 Sep 2012 10:59:29 EDT." <20120911145928.GC20895@mx1.yitter.info> Date: Tue, 11 Sep 2012 16:57:08 -0400 Cc: homenet@ietf.org Subject: Re: [homenet] Unicast DNS within the Homenet? 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, 11 Sep 2012 20:57:17 -0000 In message <20120911145928.GC20895@mx1.yitter.info> Andrew Sullivan writes: > On Tue, Sep 11, 2012 at 02:45:12PM +0100, Brian E Carpenter wrote: > > Thanks. Then it seems to me that a recommendation about the desirable behaviour > > of getnameinfo() and getaddrinfo() needs to be made, consistent with the final > > recommendation for mDNS vs DNS. At least we should describe a consistent > > deployment scenario. > > But you can't _make_ such a recommendation, because different > scenarios -- network-topologically indistinguishable from one another > -- require very different conclusions. > > This is exactly the same problem MIF faced with the DNS server > selection logic. You naturally want to use the DNS server that you > believe is going to provide you with the right answers. But when you > move networks (say, into the coffeeshop which is using Stupid DNS > Tricks to authenticate you as a customer first), you actually need the > _least good_ answer sometimes, in order to move you from your > expensive mobile radio onto your cheap wifi. > > The same problem crops up here. Inside your house, mDNS is perhaps > the right answer. But for bookmarking on your laptop that you carry > on the road but want to use with your home network then, it's exactly > the wrong answer. So this once again comes down to use cases, and > trading userland functionality against complications that make the > specification complex, and implementations tricky and therefore buggy. > > To moan just a little bit, this is why many of us think that the > mutliple namespace approaches (seen in mDNS, llmnr, before those > NetBIOS, and so on) are harmful. Inevitably, these systems get hooked > up to the wider Internet, and the inconsistencies thereby revealed > make people confused. (This isn't to say there is an obvious better > answer, given the facts of the world about DNS name registration and > resolution.) > > Best, > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com Andrew, +1 I agree that multiple namespaces are harful, and multiple additional namespaces of mDNS, llmnr, NetBIOS even more harmful. So the question is what motivated these rather than use DNS. For mDNS and I think the others it was the absense of a need to provide and pick a DHCP/dynDNS server and just multicast the identities, plus simple service discovery (though admitedly confined to a single subnet). So lets solve this for DHCP/dynDNS. I'll start with the simplest cases and move to more involved. In the case where there is nothing but a computer and printer, either the computer needs to volunteer to be DHCP server and dynDNS nameserver or addresses and names don't exist. With IPv4 and mDNS and no DHCP server there are still no addresses (unless things default to 192.168.0.1 or similar). With IPv6 there are ULA that can be used and then its just a matter of naming. If DNS is used in the above scenario, then something has to come up as the DHCP/DNS server and do dynDNS, in this case just collecting the name/ULA mapping. If a router comes up and has a GUA prefix, there needs to be a way for the computer to transfer control to the router. With DHCP server preference set appropriately, with FORCERENEW and Forcerenew Nonce Authentication, this is acheivable and reasonably secure. A multicast "I'm a DHCP server and just came up" would trigger anything acting as a DHCP server to take notice. For IPv6 this could be sent to the All_DHCP_Relay_Agents_and_Servers multicast address. AFAIK DHCP relays and servers and configured and there is no mechanism available for servers to dynamically discover other DHCP servers and coordinate as peers. The above would require very little change to DHCP or DNS. Other than that it is just usage and therefore an Information RFC or BCP is all that is needed. The case where a router comes up but has no GUA prefix and sits on two subnets also has to be handled. In that case the router may have priority over computers offering DHCP/dynDNS and the same can occur, with the router providing names and routes to ULA on each subnet. Again, no change to DHCP or DNS, just usage. If more than one router comes up and none have a GUA prefix, then they must make names available. Collecting name/ULA mappings is the same there is no means to coordinate the DNS namespace so that Router-A can announce name/ULA mappings for devices connected only to Router-B. Here an extension is needed. One possibility is that each subnet becomes a DNS zone and exactly one router connected to that subnet is selected to do DHCP/dynDNS for that subnet. The other routers must discover each other and exchange names. Reasonable default names is also an issue. Two routers named "linksys" doesn't help, just as two printers named "printer1" doesn't help. I'm not sure how (or if) mDNS solves the latter problem. I suspect it doesn't. What might be needed is a means for a DHCP server to assign a host name based on what the client sent with a digit (or two if needed) appended to the conflicting name. A similar technique could be applied to routers coming up with the same name. In past postings I have suggested that a router without a GUA prefix snd a DHCP request as a client first and try to obtain a GUA prefix, and absent of that try to negociate with other DHCP servers over what address to use and how to divide up the sitelocal name space. Another case is where a router comes up and has a GUA prefix or has discovered one (service provider link came up, one got configured, etc). A lot of FORCERENEW exchanges would occur and hosts would get GUA addresses. Subdividing the GUA prefix would be based on number of hosts reported per subnet and margins for growth to avoid additional FORCERENEW as new hosts came up on an existing subnet. Another case for address allocation is more than one router coming up with different GUA prefixes. Each would subdivide, and hosts could now be offerred more than one address (if DHCP supported it) or a tie breaker is need (shortest route, plus other tie breaker) to pick a GUA. The former is better so a change in route costs does not require a FORCERENEW. The last case for address allocation is more than one router with the same GUA prefix. One has to be picked to subdivide the GUA prefix. Otherwise not much changes. A second dimension is the root of the namespace. If the initial root is .sitelocal and a router comes up with (or somehow discovers) a DNS domain for which it is authoritative (ie: primary), then FORCERENEW is needed to change the domain name and likely also the DNS nameserver list, though other routers could be granted secondary. The dynamic namespace can then be subdivided among subnets creating zones in the DNS namespace rooted at "." rather than at ".sitelocal". btw- Using DNSSEC with ".sitelocal" requires manual key exchange and may not be practical. If two (or more) routers come up with different namespaces rooted at ".", then the addresses space can be in both forward lookups. If there are also two (or more) GUA (highly likely) then the rDNS for the GUA provided by each router can point to the zone provided by that router if it is also authoritative for a GUA prefix. The only other motivation for mDNS and friends is service discovery. LL scope multicast work on a subnet. Site local multicast is now depricated but prior proposals for service discovery anycast have suggested gradually increasing TTL on a globally scoped multicast. The semantics here are different from mDNS and friends. In mDNS a LL multicast says "I am a " where in anycast the host says "are there any out there" and can therefore find services off subnet by increasing TTL until is found. (ie: printer). Curtis From curtis@occnc.com Tue Sep 11 14:14: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 A9A0F21E8039 for ; Tue, 11 Sep 2012 14:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[AWL=-0.850, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_25=0.6, 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 3XiKWJPsxWIP for ; Tue, 11 Sep 2012 14:14:37 -0700 (PDT) Received: from gateway1.orleans.occnc.com (gateway1.orleans.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id E7D5321F8682 for ; Tue, 11 Sep 2012 14:14:36 -0700 (PDT) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id q8BLEB34025455; Tue, 11 Sep 2012 17:14:13 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201209112114.q8BLEB34025455@gateway1.orleans.occnc.com> To: Michael Thomas From: Curtis Villamizar In-reply-to: Your message of "Tue, 11 Sep 2012 09:24:39 PDT." <504F65C7.4010501@mtcc.com> Date: Tue, 11 Sep 2012 17:14:11 -0400 Cc: Ray Bellis , Kerry Lynn , Ted Lemon , "homenet@ietf.org Group" , james woodyatt Subject: Re: [homenet] Unicast DNS within the Homenet? 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, 11 Sep 2012 21:14:37 -0000 In message <504F65C7.4010501@mtcc.com> Michael Thomas writes: > On 09/11/2012 09:01 AM, Ted Lemon wrote: > > > There are a couple of options being pursued in the DHC working > > group; the DHCP address registration process would be an obvious > > mechanism for leveraging DHCP to populate the DNS. The idea here is > > that you do RA+SLAAC, or RA+CGA, and then you contact the DHCP > > server to tell it what address you allocated and what name you want > > associated with it, and to get any local network configuration > > information you might need. > > Maybe somebody can educated me, but isn't it a bit dangerous to use an > auto-configured address as a way to contact a host? If I change out my > ethernet hardware, for example, my auto-conf address would normally > change too, right? > > > However, of course this is new technology that isn't even > > standardized yet. I'd like it if homenet recommended implementing > > this, but I think another way of populating the DNS is through mDNS—w > > hen a host publishes its name in mDNS, it's assumed to be valid as > > long as no conflicting registration has been made locally. I don't > > particularly love this method because mDNS doesn't have the same > > duplicate detection features that DHCP does through the DUID, but it > > wouldn't be _worse_ than plain mDNS, and would allow the DNS > > resolver to query a consistent FQDN tree for local names, so that it > > would work whether you were attached to the local wire or not. > > DHCP may be a solution but it ought not be the only solution, right? > What if there's no relationship between my dns repository and the DHCP > server? That is, suppose that Google hosted my DNS and thus wasn't > actually on my home network. I suppose that a home router could work > in concert by either working with its DHCP or listening to mdns > chatter and then doing IXFR's to a name server. Is that what's being > talked about? > > Mike Mike, > suppose that Google hosted my DNS Create a zone names . and then you can have a zone for which dyn-DNS is authoritative. At that point the dynDNS server and DHCP server need not be the same host, just both under your control and able to use the dynDNS protocol to populate the dynDNS domain (the subdomain in the prior example). Unless of course you can convince Google to honor dynDNS from your DHCP server (hint: no chance, create a subdomain if you want dynDNS). If Google is a secondary, not primary, then problem solved. Personally I have stayed away from mDNS, compiling out avahi (mDNS) or bonjour or anything similar in any port that offerred it. Curtis From curtis@occnc.com Tue Sep 11 15:16:09 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9474521E8045 for ; Tue, 11 Sep 2012 15:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.68 X-Spam-Level: X-Spam-Status: No, score=-2.68 tagged_above=-999 required=5 tests=[AWL=-0.080, 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 wl5dytq3PR0i for ; Tue, 11 Sep 2012 15:16:09 -0700 (PDT) Received: from gateway1.orleans.occnc.com (gateway1.orleans.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id E7A2021F85F0 for ; Tue, 11 Sep 2012 15:16:08 -0700 (PDT) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id q8BMG1tA025818; Tue, 11 Sep 2012 18:16:01 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201209112216.q8BMG1tA025818@gateway1.orleans.occnc.com> To: Evan Hunt From: Curtis Villamizar In-reply-to: Your message of "Tue, 11 Sep 2012 18:07:43 -0000." <20120911180743.GD15012@isc.org> Date: Tue, 11 Sep 2012 18:16:00 -0400 Cc: Kerry Lynn , Michael Thomas , Ted Lemon , Ray Bellis , james woodyatt , "homenet@ietf.org Group" Subject: Re: [homenet] Unicast DNS within the Homenet? 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, 11 Sep 2012 22:16:09 -0000 In message <20120911180743.GD15012@isc.org> Evan Hunt writes: > On Tue, Sep 11, 2012 at 12:37:30PM -0400, Ted Lemon wrote: > > No. Things change. All that's required to deal with this is that the > > underlying protocol support it. The DHCP DUID identification system > > does support this kind of change, as long as the actual device doesn't > > change. If the device changes, then when the registration expires, the > > name can be reclaimed. > > This does raise a point, though: Dynamic DNS doesn't have an expiration > mechanism. Populating the DNS using mDNS is a good idea, I think, but it > might be nice if we had some method of signaling the intended future > disposation of a name. > > I'm thinking along the lines of a new rrtype, or maybe just a TXT record, > that can indicate things like "after time T, it's okay to delete this > rrset", or "if this name already exists with a different address, it's > okay to replace the old one instead of adding to it". > > My home zone is cluttered up with the names of a couple of dozen laptops > and ipods belonging to neighbors and visitors over the past year. It's > probably my own fault for misconfiguring DHCP (I don't think it's doing > the right thing in the "on expiry" block, and it hasn't been a high > priority for me to fix it). But if we're going to be supplying DNS > data from multiple sources -- DHCP, mDNS, maybe others -- then it might > be a good idea to manage time limits on the demand side. > > -- > Evan Hunt -- each@isc.org > Internet Systems Consortium, Inc. Even, I've avoided that problem with the opposite approach. I have both fixed DNS and DHCP fixed entries for the laptops in my home. Anything else gets an address from the pool and no name except in the DHCP leases file. The only "anything else" is grandpa's laptop when he visits and my kids laptops when they are home, or other guests. I also get a stupid name based on serial number from one appliance that doesn't allow the name to be changed and also don't allow a fixed address to be configured. At least I know what it is and I can define a meaningful DNS name for it even if it won't take one. If my wife or I take a laptop elsewhere, to the library for example (or to IETF), then DHCP gives me a different address. No big deal but also no reconfig to go elsewhere. A bit deal for my wife, but then again she leaves her laptop at home all the time. I also have two mystery devices with a uid and no client-hostname. Not pingable. Hmm. :-( I would think that the dynDNS name would go away if the DHCP lease expired. Apparently not. I'd call that a bug. Curtis From curtis@occnc.com Tue Sep 11 15:21:58 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 657ED21F861A for ; Tue, 11 Sep 2012 15:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.667 X-Spam-Level: X-Spam-Status: No, score=-2.667 tagged_above=-999 required=5 tests=[AWL=-0.067, 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 ljWgiccEPyr5 for ; Tue, 11 Sep 2012 15:21:58 -0700 (PDT) Received: from gateway1.orleans.occnc.com (gateway1.orleans.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id CE7C521F8613 for ; Tue, 11 Sep 2012 15:21:57 -0700 (PDT) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id q8BMLqwf025830; Tue, 11 Sep 2012 18:21:52 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201209112221.q8BMLqwf025830@gateway1.orleans.occnc.com> To: james woodyatt From: Curtis Villamizar In-reply-to: Your message of "Tue, 11 Sep 2012 11:29:48 PDT." Date: Tue, 11 Sep 2012 18:21:52 -0400 Cc: Evan Hunt , "homenet@ietf.org Group" Subject: Re: [homenet] Unicast DNS within the Homenet? 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, 11 Sep 2012 22:21:58 -0000 In message james woodyatt writes: > On Sep 11, 2012, at 11:07 , Evan Hunt wrote: > > > > This does raise a point, though: Dynamic DNS doesn't have an expiration mechanism. [...] My home zone is cluttered up with the names of a couple of dozen laptops and ipods belonging to neighbors and visitors over the past year. [...] > > I recommend reading section 5 of "Understanding Apple's Back-to-My-Mac > Service" [RFC 6281], which gives a brief summary of how this problem > is effectively and reliably managed in that system. There you will > find references to the following truly under-loved technical > specifications: > > > > > Maybe HOMENET could push for these to be taken up as IETF work items? > -- > james woodyatt > member of technical staff, core os networking Or maybe not. The situation right now is multiple name and service discovery protocols for Window PC, multiple name and service discovery protocols for Apple, and multiple name and service discovery protocols for Linux and very limited intersection between them, plus they all only work on a single subnet and therefore are useless in anything but homes and the most tiny soho or enterprise. If dynDNS doesn't delete with the lease expire, that just a bug. Curtis From curtis@occnc.com Tue Sep 11 16:53: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 8F7DE21F858F for ; Tue, 11 Sep 2012 16:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.657 X-Spam-Level: X-Spam-Status: No, score=-2.657 tagged_above=-999 required=5 tests=[AWL=-0.057, 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 DXKbWxZ1xc6n for ; Tue, 11 Sep 2012 16:53:51 -0700 (PDT) Received: from gateway1.orleans.occnc.com (gateway1.orleans.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id F0DC721F8595 for ; Tue, 11 Sep 2012 16:53:50 -0700 (PDT) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id q8BNrcw5026314; Tue, 11 Sep 2012 19:53:40 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201209112353.q8BNrcw5026314@gateway1.orleans.occnc.com> To: Michael Thomas From: Curtis Villamizar In-reply-to: Your message of "Tue, 11 Sep 2012 13:07:39 PDT." <504F9A0B.1080604@mtcc.com> Date: Tue, 11 Sep 2012 19:53:37 -0400 Cc: Kerry Lynn , Ted Lemon , Ray Bellis , james woodyatt , Evan Hunt , "homenet@ietf.org Group" Subject: Re: [homenet] Unicast DNS within the Homenet? 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, 11 Sep 2012 23:53:51 -0000 In message <504F9A0B.1080604@mtcc.com> Michael Thomas writes: > On 09/11/2012 11:07 AM, Evan Hunt wrote: > > > My home zone is cluttered up with the names of a couple of dozen > > laptops and ipods belonging to neighbors and visitors over the past > > year. It's probably my own fault for misconfiguring DHCP (I don't > > think it's doing the right thing in the "on expiry" block, and it > > hasn't been a high priority for me to fix it). But if we're going to > > be supplying DNS data from multiple sources -- DHCP, mDNS, maybe > > others -- then it might be a good idea to manage time limits on the > > demand side. > > A more fundamental question is enrollment. Security considerations are > usually the sworn enemy of zeroconf like solutions. How we make those > tradeoffs will most likely be a difficult conversation. What gives > something on my home network the right to announce itself, offer > services, change state in some repository, etc, etc? > > If we're using the property that they need to have access to my home > wifi as proof the device is "mine" rather than "somebody else's", then > lets stop right now with the posture that what we're doing is > "zeroconf" because configuring a wifi password is most certainly not > "zeroconf". We had a similar discussion before and I pointed out that for security some form of exchange of keys or certificates was needed. Having a factory configured root DNSSEC certificate gets one form of trust anchor. The browser certificates provide another, possibly very flawed forn of trust anchor. A means to create a local certificate and manually distribute this could be the basis of a local trust anchor for local addresses and names. For specific services it may be best to have certificates or keys exchanged between client and server. > Which brings me to: we shouldn't be hung up with "zeroconf", we should > be shooting for "littleconf". Agree. Insecure with zeroconf. Secure with littleconf. And insecure is bad. Very bad with GUA. > Mike Curtis From mike@mtcc.com Tue Sep 11 18:14: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 CBE8F21F85AD for ; Tue, 11 Sep 2012 18:14:29 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VDg5v4esaxfM for ; Tue, 11 Sep 2012 18:14:29 -0700 (PDT) Received: from mtcc.com (mtcc.com [IPv6:2001:5a8:4:9fe0:224:8cff:feaa:6d9b]) by ietfa.amsl.com (Postfix) with ESMTP id D639A21F85A7 for ; Tue, 11 Sep 2012 18:14:28 -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 q8C1EICS008473 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 11 Sep 2012 18:14:18 -0700 Message-ID: <504FE1EA.90800@mtcc.com> Date: Tue, 11 Sep 2012 18:14: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: curtis@occnc.com References: <201209112353.q8BNrcw5026314@gateway1.orleans.occnc.com> In-Reply-To: <201209112353.q8BNrcw5026314@gateway1.orleans.occnc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1393; t=1347412462; x=1348276462; 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]=20Unicast=20DNS=20within=20th e=20Homenet? |Sender:=20 |To:=20curtis@occnc.com |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=D3x4FEjiwX3Vx1XOmMMFZ9kqPcwW5DOlmLTEwFptWIA=; b=Yx/9GcKfBOlLO2ZJQiZLCpa8zCf0zKRIU+8rICftAylSX51H164WXYx+bg OXfkDAEnhksBOYbcDJmy+eGHDJvj/1Unc7Dw6pX+0tkGvAEd5T2hyEI6TWXj uSm2nQ40kwsuaOFpUUFvefYUcZMhc46zT4FM/cFjEbD6ywQQ0sibk=; 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 , Ray Bellis , james woodyatt , Evan Hunt , "homenet@ietf.org Group" Subject: Re: [homenet] Unicast DNS within the Homenet? 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, 12 Sep 2012 01:14:29 -0000 On 09/11/2012 04:53 PM, Curtis Villamizar wrote: > In message <504F9A0B.1080604@mtcc.com> > Michael Thomas writes: > > If we're using the property that they need to have access to my home > wifi as proof the device is "mine" rather than "somebody else's", then > lets stop right now with the posture that what we're doing is > "zeroconf" because configuring a wifi password is most certainly not > "zeroconf". > We had a similar discussion before and I pointed out that for security > some form of exchange of keys or certificates was needed. Here is usually where IETF usually wraps around the axle. I'm not saying that "has my wifi password, therefore is allowed" is bad, I'm just saying that it's not zeroconf. We need to be extremely careful that the best is the enemy of the good. At the point that we're talking about certs we've almost certainly wandered into something well beyond "littleconf". If we can get by with "has my wifi password" or similar, we're still probably on track. Or maybe ssh-like leap of faith kinds of bare public key enrollment is ok. In any case, my larger point is that "littleconf" might also involve having to give a name to some of my devices so that I don't have to remember that megacorp-light-switch-1279385xxc7 is the front room mood lighting in addition to giving it my wifi password for the home automation SSID. Mike From curtis@occnc.com Tue Sep 11 19:37: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 8830521E8042 for ; Tue, 11 Sep 2012 19:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.65 X-Spam-Level: X-Spam-Status: No, score=-2.65 tagged_above=-999 required=5 tests=[AWL=-0.050, 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 5QwIx2CeOUBj for ; Tue, 11 Sep 2012 19:37:06 -0700 (PDT) Received: from gateway1.orleans.occnc.com (gateway1.orleans.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id D0D9821E8037 for ; Tue, 11 Sep 2012 19:37:05 -0700 (PDT) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id q8C2ag2b027265; Tue, 11 Sep 2012 22:36:44 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201209120236.q8C2ag2b027265@gateway1.orleans.occnc.com> To: Michael Thomas From: Curtis Villamizar In-reply-to: Your message of "Tue, 11 Sep 2012 18:14:18 PDT." <504FE1EA.90800@mtcc.com> Date: Tue, 11 Sep 2012 22:36:42 -0400 Cc: Kerry Lynn , Ted Lemon , curtis@occnc.com, Ray Bellis , james woodyatt , Evan Hunt , "homenet@ietf.org Group" Subject: Re: [homenet] Unicast DNS within the Homenet? 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, 12 Sep 2012 02:37:06 -0000 In message <504FE1EA.90800@mtcc.com> Michael Thomas writes: > On 09/11/2012 04:53 PM, Curtis Villamizar wrote: > > In message <504F9A0B.1080604@mtcc.com> > > Michael Thomas writes: > > > > If we're using the property that they need to have access to my home > > wifi as proof the device is "mine" rather than "somebody else's", then > > lets stop right now with the posture that what we're doing is > > "zeroconf" because configuring a wifi password is most certainly not > > "zeroconf". > > We had a similar discussion before and I pointed out that for security > > some form of exchange of keys or certificates was needed. > > Here is usually where IETF usually wraps around the axle. I'm not > saying that "has my wifi password, therefore is allowed" is bad, I'm > just saying that it's not zeroconf. We need to be extremely careful > that the best is the enemy of the good. At the point that we're talking > about certs we've almost certainly wandered into something well > beyond "littleconf". If we can get by with "has my wifi password" > or similar, we're still probably on track. Or maybe ssh-like leap of > faith kinds of bare public key enrollment is ok. "keys or certificates" would include public/private key pairs like the rsa or dsa keys that ssh uses. > In any case, my larger point is that "littleconf" might also involve having > to give a name to some of my devices so that I don't have to remember > that megacorp-light-switch-1279385xxc7 is the front room mood lighting > in addition to giving it my wifi password for the home automation SSID. > > Mike And my SIP phone has a serial number for a host name. One problem is that some clueless programmers have allowed any characters to be entered into the host name string, so DHCP can return a hostname that has more than just DNS allowed characters. I'm not sure %20 and other substitutes legal in URLs are legal in hostnames. I don't think so. Its OK to have "Bill's Laptop" in the leases file, but you can't put that into a DNS hostname and "Bill T. Cat's Laptop" would be worse because of the dot. But you might get this from DHCP. Maybe a good start for homenet is recommendations on what should be setable on any home device and constraints (hostnames within valid DNS character set being one example). Allowing a fixed address is another (my SIP phone DNS client is a bit broken and doesn't always renew before the lease expires and then locks up if the address changes). Supporting IPv6 is yet another. Curtis From mellon@fugue.com Tue Sep 11 19:57: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 A6E4621F8504 for ; Tue, 11 Sep 2012 19:57:24 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i2ChvEP-7WRc for ; Tue, 11 Sep 2012 19:57:24 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 4C7E121F8501 for ; Tue, 11 Sep 2012 19:57:24 -0700 (PDT) Received: from kali.lan (c-174-62-144-132.hsd1.nh.comcast.net [174.62.144.132]) by toccata.fugue.com (Postfix) with ESMTPSA id E12912380CC0; Tue, 11 Sep 2012 22:57:21 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Ted Lemon In-Reply-To: <201209112221.q8BMLqwf025830@gateway1.orleans.occnc.com> Date: Tue, 11 Sep 2012 22:57:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4FC10A5A-3201-4230-8D9C-6BBD3BC3EA02@fugue.com> References: <201209112221.q8BMLqwf025830@gateway1.orleans.occnc.com> To: curtis@occnc.com X-Mailer: Apple Mail (2.1486) Cc: Evan Hunt , "homenet@ietf.org Group" , james woodyatt Subject: Re: [homenet] Unicast DNS within the Homenet? 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, 12 Sep 2012 02:57:24 -0000 On Sep 11, 2012, at 6:21 PM, Curtis Villamizar wrote: > If dynDNS doesn't delete with the lease expire, that just a bug. At least the ISC and Nominum DHCP servers automatically delete the = dynamic name when the lease expires. I assume Cisco's does as well. = Your point about widespread protocol support is a good one=97I have a = lot of trouble getting consistent behavior out of mDNS. I have no = problem getting consistent behavior out of DNS. From v6ops@globis.net Tue Sep 11 23:41: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 01AA821F84E2 for ; Tue, 11 Sep 2012 23:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.913 X-Spam-Level: X-Spam-Status: No, score=-1.913 tagged_above=-999 required=5 tests=[AWL=-0.514, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_25=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 PCLRcVS3UYa6 for ; Tue, 11 Sep 2012 23:41:56 -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 2D8A521F84DF for ; Tue, 11 Sep 2012 23:41:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id E9503870106; Wed, 12 Sep 2012 08:41:38 +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 4tQgt2aa8Sam; Wed, 12 Sep 2012 08:41:18 +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 DEB1F8700D7; Wed, 12 Sep 2012 08:41:17 +0200 (CEST) Message-ID: <50502E87.6030402@globis.net> Date: Wed, 12 Sep 2012 08:41:11 +0200 From: Ray Hunter User-Agent: Postbox 3.0.4 (Macintosh/20120616) MIME-Version: 1.0 To: Ted Lemon References: <47437C06-FB3D-41AB-ADB9-01A4091640E1@nominet.org.uk> <9466256C-546F-4EEE-9F94-CBF0C4E5967C@apple.com> <504F4210.9040700@mtcc.com> <0EBBAAF8-CF07-45B8-897C-C4CC69CC57F7@fugue.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: Ray Bellis , Kerry Lynn , Michael Thomas , "homenet@ietf.org Group" , james woodyatt Subject: Re: [homenet] Unicast DNS within the Homenet? 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, 12 Sep 2012 06:41:57 -0000 Ted, respect your DHCP/DNS knowledge, but if we need a DHCP server anyway in Homenet, why don't we go for the classic enterprise set up that has run for years for IPv4, rather than trying to shoe horn locally assigned SLAAC addresses into global DNS? It's not as though you can buy any piece of domestic networking equipment today that does not support DHCPv4, so why not DHCPv6? So we'd have: Homenet router <-> ISP = DHCP-PD to learn prefixes [existing] in Homenet prefix allocation & distribution [work in progress] DHCPv6 from the Homenet router to the ISP could be extended to communicate any ISP DNS domain settings to the Homenet [gap] elect/configure a unicast DNS server for Homenet [gap] run standard unicast DNS [existing] elect/configure a DHCPv6 server for use within Homenet [gap] The routers that are acting as clients for DHCP-PD would seem good candidates. run standard DHCPv6 server on local Homenet router[existing] configure DHCPv6 relay per Homenet router to point to Homenet DHCPv6 server[existing standard, although autoconfig is a gap for the election process] use DHCPv6 server to update DNS content using RFC 2316 Dynamic DNS update on behalf of end clients [existing] client -> Homenet router RFC 3315 DHCPv6 based address configuration, and standard unicast DNS [existing] Then the client only needs to do stuff that is already incorporated in any operating system used in business. Or is this stateless /stateful war still too fresh in the collective IETF memory? Ted Lemon wrote: > On Sep 11, 2012, at 11:17 AM, Kerry Lynn wrote: >> Can we explore how this auto-population might occur? It seems that to >> glean bindings from mDNS or LLMNR there would have to be at least >> (or exactly?) one "agent" per subnet. The natural place for the agent to >> reside is on the router. Presumably each agent learns the address of >> the DNS server via stateless DHCPv6. The DNS server would need to >> be configured with a TSIG for each agent. The agent hears multicast >> responses to lookups on its local link, then periodically updates the >> DNS server. >> >> I assume an alternative would be to auto-configure via stateful DHCPv6. >> Would that more or less of a configuration burden than the sketch above? >> Would work with existing devices? > > There are a couple of options being pursued in the DHC working group; the DHCP address registration process would be an obvious mechanism for leveraging DHCP to populate the DNS. The idea here is that you do RA+SLAAC, or RA+CGA, and then you contact the DHCP server to tell it what address you allocated and what name you want associated with it, and to get any local network configuration information you might need. > > However, of course this is new technology that isn't even standardized yet. I'd like it if homenet recommended implementing this, but I think another way of populating the DNS is through mDNS—when a host publishes its name in mDNS, it's assumed to be valid as long as no conflicting registration has been made locally. I don't particularly love this method because mDNS doesn't have the same duplicate detection features that DHCP does through the DUID, but it wouldn't be _worse_ than plain mDNS, and would allow the DNS resolver to query a consistent FQDN tree for local names, so that it would work whether you were attached to the local wire or not. > > From mellon@fugue.com Wed Sep 12 05:36:58 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A74EA21F85A2 for ; Wed, 12 Sep 2012 05:36:58 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSKaNUNn1nxn for ; Wed, 12 Sep 2012 05:36:58 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 444BA21F859B for ; Wed, 12 Sep 2012 05:36:58 -0700 (PDT) Received: from kali.lan (c-174-62-144-132.hsd1.nh.comcast.net [174.62.144.132]) by toccata.fugue.com (Postfix) with ESMTPSA id 2E0612380CAC; Wed, 12 Sep 2012 08:36:54 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Ted Lemon In-Reply-To: <50502E87.6030402@globis.net> Date: Wed, 12 Sep 2012 08:36:54 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <47437C06-FB3D-41AB-ADB9-01A4091640E1@nominet.org.uk> <9466256C-546F-4EEE-9F94-CBF0C4E5967C@apple.com> <504F4210.9040700@mtcc.com> <0EBBAAF8-CF07-45B8-897C-C4CC69CC57F7@fugue.com> <50502E87.6030402@globis.net> To: Ray Hunter X-Mailer: Apple Mail (2.1486) Cc: Ray Bellis , Kerry Lynn , Michael Thomas , "homenet@ietf.org Group" , james woodyatt Subject: Re: [homenet] Unicast DNS within the Homenet? 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, 12 Sep 2012 12:36:58 -0000 On Sep 12, 2012, at 2:41 AM, Ray Hunter wrote: > Ted, respect your DHCP/DNS knowledge, but if we need a DHCP server = anyway in Homenet, why don't we go for the classic enterprise set up = that has run for years for IPv4, rather than trying to shoe horn locally = assigned SLAAC addresses into global DNS? Two reasons. First, there's strong opposition to this, and so it will = never happen, whether it is the right idea or not (I don't think it's = particularly the right idea, although I'm not vehemently opposed to it = either). Secondly, it precludes the use of CGA by hosts. From marka@isc.org Wed Sep 12 18:02: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 550DE21F8697 for ; Wed, 12 Sep 2012 18:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.104, 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 b1rBWpm1Fnln for ; Wed, 12 Sep 2012 18:02:23 -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 694D421F8694 for ; Wed, 12 Sep 2012 18:02: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 207695F994E; Thu, 13 Sep 2012 01:02:10 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:906e:c9d3:f8c0:7a5]) (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 25E1D216C6D; Thu, 13 Sep 2012 01:02:09 +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 6A24D24F6237; Thu, 13 Sep 2012 11:02:02 +1000 (EST) To: Ted Lemon From: Mark Andrews References: <47437C06-FB3D-41AB-ADB9-01A4091640E1@nominet.org.uk> <9466256C-546F-4EEE-9F94-CBF0C4E5967C@apple.com> <504F4210.9040700@mtcc.com> <0EBBAAF8-CF07-45B8-897C-C4CC69CC57F7@fugue.com> <50502E87.6030402@globis.net> In-reply-to: Your message of "Wed, 12 Sep 2012 08:36:54 -0400." Date: Thu, 13 Sep 2012 11:02:01 +1000 Message-Id: <20120913010202.6A24D24F6237@drugs.dv.isc.org> Cc: Kerry Lynn , Michael Thomas , Ray Bellis , Ray Hunter , james woodyatt , "homenet@ietf.org Group" Subject: Re: [homenet] Unicast DNS within the Homenet? 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, 13 Sep 2012 01:02:24 -0000 In message , Ted Lemon writes: > On Sep 12, 2012, at 2:41 AM, Ray Hunter wrote: > > Ted, respect your DHCP/DNS knowledge, but if we need a DHCP server anyway i > n Homenet, why don't we go for the classic enterprise set up that has run for > years for IPv4, rather than trying to shoe horn locally assigned SLAAC addre > sses into global DNS? > > Two reasons. First, there's strong opposition to this, and so it will never > happen, whether it is the right idea or not (I don't think it's particularly > the right idea, although I'm not vehemently opposed to it either). Secondl > y, it precludes the use of CGA by hosts. Note updating DNS involves both FORWARD and REVERSE entries and the solutions can be different. My machines have names. Those names don't change as I move around the world. Random DHCP servers at coffee shops DO NOT have the ability to update the DNS entries for those names. They do have the authority to update the PTR records in in-addr.arpa and ip6.arpa namespaces. Machines start off with mDNS to avoid bootstrap problems. They then have the ability to get a TSIG using TKEY signed with a administrators TSIG (think Username/Password pair) for the forward zone. This will be stored in non-volitile storage on the master nameserver and on the client. Once the client has the TSIG key it uses that to update its own forward entries. Machines register PTR records in the reverse zones using TCP as the authenticator in the reverse zone unless there is a DHCP option that says to use the DHCP server to relay the PTR record update. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From mellon@fugue.com Wed Sep 12 18:57: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 711A521F8620 for ; Wed, 12 Sep 2012 18:57:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 k2+r-fDwDMgy for ; Wed, 12 Sep 2012 18:57:13 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id D307921F861F for ; Wed, 12 Sep 2012 18:57:13 -0700 (PDT) Received: from kali.lan (c-174-62-144-132.hsd1.nh.comcast.net [174.62.144.132]) by toccata.fugue.com (Postfix) with ESMTPSA id B2DA02380621; Wed, 12 Sep 2012 21:57:10 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Ted Lemon In-Reply-To: <20120913010202.6A24D24F6237@drugs.dv.isc.org> Date: Wed, 12 Sep 2012 21:57:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7E23E81A-9DAA-45AC-A577-3B0574E1DE1F@fugue.com> References: <47437C06-FB3D-41AB-ADB9-01A4091640E1@nominet.org.uk> <9466256C-546F-4EEE-9F94-CBF0C4E5967C@apple.com> <504F4210.9040700@mtcc.com> <0EBBAAF8-CF07-45B8-897C-C4CC69CC57F7@fugue.com> <50502E87.6030402@globis.net> <20120913010202.6A24D24F6237@drugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1486) Cc: Kerry Lynn , Michael Thomas , Ray Bellis , Ray Hunter , james woodyatt , "homenet@ietf.org Group" Subject: Re: [homenet] Unicast DNS within the Homenet? 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, 13 Sep 2012 01:57:14 -0000 On Sep 12, 2012, at 9:02 PM, Mark Andrews wrote: > My machines have names. Those names don't change as I move around > the world. Random DHCP servers at coffee shops DO NOT have the > ability to update the DNS entries for those names. They do have the > authority to update the PTR records in in-addr.arpa and ip6.arpa > namespaces. We're not talking about mobile IP here=97we''re talking about naming in = the homenet. The technology has existed for over a decade to do what = you describe with DHCP and DDNS in IPv4, but AFAIK nobody uses it, for = two reasons: one, I don't think it actually serves a real need, and two, = it requires geek skills to set up, which most people don't have. But = the second point is really a footnote to the first. There's a draft in the DHC working group for setting up the reverse = zone... From marka@isc.org Wed Sep 12 19:29:06 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27CCF21E803F for ; Wed, 12 Sep 2012 19:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 7btLL+uJ6veF for ; Wed, 12 Sep 2012 19:29:04 -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 BBB8621E8034 for ; Wed, 12 Sep 2012 19:29:04 -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 1B882C95AB; Thu, 13 Sep 2012 02:28:54 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (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 D2E25216C6F; Thu, 13 Sep 2012 02:28:53 +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 A98D624F6C39; Thu, 13 Sep 2012 12:28:41 +1000 (EST) To: Ted Lemon From: Mark Andrews References: <47437C06-FB3D-41AB-ADB9-01A4091640E1@nominet.org.uk> <9466256C-546F-4EEE-9F94-CBF0C4E5967C@apple.com> <504F4210.9040700@mtcc.com> <0EBBAAF8-CF07-45B8-897C-C4CC69CC57F7@fugue.com> <50502E87.6030402@globis.net> <20120913010202.6A24D24F6237@drugs.dv.isc.org> <7E23E81A-9DAA-45AC-A577-3B0574E1DE1F@fugue.com> In-reply-to: Your message of "Wed, 12 Sep 2012 21:57:09 -0400." <7E23E81A-9DAA-45AC-A577-3B0574E1DE1F@fugue.com> Date: Thu, 13 Sep 2012 12:28:40 +1000 Message-Id: <20120913022841.A98D624F6C39@drugs.dv.isc.org> Cc: Kerry Lynn , Michael Thomas , Ray Bellis , Ray Hunter , james woodyatt , "homenet@ietf.org Group" Subject: Re: [homenet] Unicast DNS within the Homenet? 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, 13 Sep 2012 02:29:06 -0000 In message <7E23E81A-9DAA-45AC-A577-3B0574E1DE1F@fugue.com>, Ted Lemon writes: > On Sep 12, 2012, at 9:02 PM, Mark Andrews wrote: > > My machines have names. Those names don't change as I move around > > the world. Random DHCP servers at coffee shops DO NOT have the > > ability to update the DNS entries for those names. They do have the > > authority to update the PTR records in in-addr.arpa and ip6.arpa > > namespaces. > > We're not talking about mobile IP here=97we''re talking about naming in the= > homenet. The technology has existed for over a decade to do what you des= > cribe with DHCP and DDNS in IPv4, but AFAIK nobody uses it, for two reasons= > : one, I don't think it actually serves a real need, More because no one looked at the whole picture and tried to get a comprehensive solution. It has multiple moving parts from multiple vendors. > and two, it requires g= > eek skills to set up, which most people don't have. Which is a UI / product support problem. The Mac has DNS registration under Sharing. It requires manual entry of the TSIG key which currently has to be entered into the nameserver for each device. It could be made as simple as BlueTooth associations are. > But the second point = > is really a footnote to the first. I have laptops that connect to the home net and then go walkabout. I suspect a large percentage of homes have some equipment that moves about. Those laptops still want to do things to the home net occasionally. Devices on the home network want to push stuff to those laptops occasionally. > There's a draft in the DHC working group for setting up the reverse zone... > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From mellon@fugue.com Wed Sep 12 20:06: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 7A6F421F850D for ; Wed, 12 Sep 2012 20:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 hwUgrKmUx1r5 for ; Wed, 12 Sep 2012 20:06:40 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 18D5C21F84FE for ; Wed, 12 Sep 2012 20:06:36 -0700 (PDT) Received: from kali.lan (c-174-62-144-132.hsd1.nh.comcast.net [174.62.144.132]) by toccata.fugue.com (Postfix) with ESMTPSA id 84DE92380621; Wed, 12 Sep 2012 23:06:31 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Ted Lemon In-Reply-To: <20120913022841.A98D624F6C39@drugs.dv.isc.org> Date: Wed, 12 Sep 2012 23:06:29 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <279CABEB-4DEE-45C7-8CF2-8C34EAC3C214@fugue.com> References: <47437C06-FB3D-41AB-ADB9-01A4091640E1@nominet.org.uk> <9466256C-546F-4EEE-9F94-CBF0C4E5967C@apple.com> <504F4210.9040700@mtcc.com> <0EBBAAF8-CF07-45B8-897C-C4CC69CC57F7@fugue.com> <50502E87.6030402@globis.net> <20120913010202.6A24D24F6237@drugs.dv.isc.org> <7E23E81A-9DAA-45AC-A577-3B0574E1DE1F@fugue.com> <20120913022841.A98D624F6C39@drugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1486) Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Unicast DNS within the Homenet? 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, 13 Sep 2012 03:06:42 -0000 On Sep 12, 2012, at 10:28 PM, Mark Andrews wrote: > Which is a UI / product support problem. The Mac has DNS registration > under Sharing. It requires manual entry of the TSIG key which > currently has to be entered into the nameserver for each device. > It could be made as simple as BlueTooth associations are. It's probably true that a homenet router could be set up to allow for = DNS updates from remote locations using a TSIG or SIG(0) signature. It = might be nice to list this as a feature if we feel it can be specified = cleanly. But as you say, it would be necessary for third party devices = to implement this, and in order for them to do that they have to = perceive a need. It could happen; I just don't think it's going to be = valued enough to motivate people do make the effort required to set it = up. I think there are a lot of steps between where we are now and an = environment where people see the need for this. From marka@isc.org Wed Sep 12 22:10:56 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6759921E803C for ; Wed, 12 Sep 2012 22:10:56 -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 7m3UJhkD6zPn for ; Wed, 12 Sep 2012 22:10:55 -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 AB81221E8034 for ; Wed, 12 Sep 2012 22:10:54 -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 0982BC942B; Thu, 13 Sep 2012 05:10:48 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:906e:c9d3:f8c0:7a5]) (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 BC15E216C3D; Thu, 13 Sep 2012 05:10:47 +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 BBA7A24F7C84; Thu, 13 Sep 2012 13:54:07 +1000 (EST) To: Ted Lemon From: Mark Andrews References: <47437C06-FB3D-41AB-ADB9-01A4091640E1@nominet.org.uk> <9466256C-546F-4EEE-9F94-CBF0C4E5967C@apple.com> <504F4210.9040700@mtcc.com> <0EBBAAF8-CF07-45B8-897C-C4CC69CC57F7@fugue.com> <50502E87.6030402@globis.net> <20120913010202.6A24D24F6237@drugs.dv.isc.org> <7E23E81A-9DAA-45AC-A577-3B0574E1DE1F@fugue.com> <20120913022841.A98D624F6C39@drugs.dv.isc.org> <279CABEB-4DEE-45C7-8CF2-8C34EAC3C214@fugue.com> In-reply-to: Your message of "Wed, 12 Sep 2012 23:06:29 -0400." <279CABEB-4DEE-45C7-8CF2-8C34EAC3C214@fugue.com> Date: Thu, 13 Sep 2012 13:54:07 +1000 Message-Id: <20120913035407.BBA7A24F7C84@drugs.dv.isc.org> Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Unicast DNS within the Homenet? 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, 13 Sep 2012 05:10:56 -0000 In message <279CABEB-4DEE-45C7-8CF2-8C34EAC3C214@fugue.com>, Ted Lemon writes: > On Sep 12, 2012, at 10:28 PM, Mark Andrews wrote: > > Which is a UI / product support problem. The Mac has DNS registration > > under Sharing. It requires manual entry of the TSIG key which > > currently has to be entered into the nameserver for each device. > > It could be made as simple as BlueTooth associations are. > > It's probably true that a homenet router could be set up to allow for = > DNS updates from remote locations using a TSIG or SIG(0) signature. It = > might be nice to list this as a feature if we feel it can be specified = > cleanly. But as you say, it would be necessary for third party devices = > to implement this, and in order for them to do that they have to = > perceive a need. It could happen; I just don't think it's going to be = > valued enough to motivate people do make the effort required to set it = > up. I think there are a lot of steps between where we are now and an = > environment where people see the need for this. MacOS already supports this so clearly someone at Apple thinks "there is a need". You turn on Active Directory in Windows and your machines will try to register themselves when on the road. This working group is looking at a paradigm shift in how home networking is done. We now have directly addressable machines on the home network. Publishing addresses to the world now makes sense for lots of reasons including we are now reachable. The "nobody is doing now" argument doesn't cut it here. Are we about enabling future development or styfling it? The world is slowly heading away from asymetric home links (cable/adls) to symetric home links (fibre) with enough bi-directional bandwidth for the home user to host whatever services that want to. We need to forward thinking enough to put in the infrastructure to support that. That means more than addresses being added to the DNS which is basically where integrated DNS/DHCP solutions stop. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From v6ops@globis.net Wed Sep 12 22:36: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 6B35521E803C for ; Wed, 12 Sep 2012 22:36:45 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BRnWXuzamD8j for ; Wed, 12 Sep 2012 22:36:44 -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 EE59621E8034 for ; Wed, 12 Sep 2012 22:36:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 053EB8700F6; Thu, 13 Sep 2012 07:36:27 +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 W5CpIpL9+2dU; Thu, 13 Sep 2012 07:35:57 +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 7CC098700E6; Thu, 13 Sep 2012 07:35:57 +0200 (CEST) Message-ID: <505170B7.1070505@globis.net> Date: Thu, 13 Sep 2012 07:35:51 +0200 From: Ray Hunter User-Agent: Postbox 3.0.4 (Macintosh/20120616) MIME-Version: 1.0 To: Mark Andrews References: <47437C06-FB3D-41AB-ADB9-01A4091640E1@nominet.org.uk> <9466256C-546F-4EEE-9F94-CBF0C4E5967C@apple.com> <504F4210.9040700@mtcc.com> <0EBBAAF8-CF07-45B8-897C-C4CC69CC57F7@fugue.com> <50502E87.6030402@globis.net> <20120913010202.6A24D24F6237@drugs.dv.isc.org> In-Reply-To: <20120913010202.6A24D24F6237@drugs.dv.isc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Kerry Lynn , Michael Thomas , Ted Lemon , Ray Bellis , james woodyatt , "homenet@ietf.org Group" Subject: Re: [homenet] Unicast DNS within the Homenet? 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, 13 Sep 2012 05:36:45 -0000 Fair counter point to my suggestion. Enterprises don't generally put laptops in public viewable DNS. Isn't your requirement to support highly mobile devices a good reason to avoid mDNS wherever possible? [mDNS being link local specific, and any extensions/gateways from mDNS to unicast DNS will also be local network specific, so your favourite coffee shop network may not support them] regards, RayH > Mark Andrews > 13 September 2012 03:02 > > Note updating DNS involves both FORWARD and REVERSE entries and the > solutions can be different. > > My machines have names. Those names don't change as I move around > the world. Random DHCP servers at coffee shops DO NOT have the > ability to update the DNS entries for those names. They do have the > authority to update the PTR records in in-addr.arpa and ip6.arpa > namespaces. > > > ------------------------------------------------------------------------ From mellon@fugue.com Thu Sep 13 05:54: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 1E8E621F847F for ; Thu, 13 Sep 2012 05:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 NaQ2eztgTAK8 for ; Thu, 13 Sep 2012 05:54:39 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 4389121F852D for ; Thu, 13 Sep 2012 05:54:39 -0700 (PDT) Received: from kali.lan (c-174-62-144-132.hsd1.nh.comcast.net [174.62.144.132]) by toccata.fugue.com (Postfix) with ESMTPSA id 34DE42380C9C; Thu, 13 Sep 2012 08:54:36 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Ted Lemon In-Reply-To: <20120913035407.BBA7A24F7C84@drugs.dv.isc.org> Date: Thu, 13 Sep 2012 08:54:35 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <47437C06-FB3D-41AB-ADB9-01A4091640E1@nominet.org.uk> <9466256C-546F-4EEE-9F94-CBF0C4E5967C@apple.com> <504F4210.9040700@mtcc.com> <0EBBAAF8-CF07-45B8-897C-C4CC69CC57F7@fugue.com> <50502E87.6030402@globis.net> <20120913010202.6A24D24F6237@drugs.dv.isc.org> <7E23E81A-9DAA-45AC-A577-3B0574E1DE1F@fugue.com> <20120913022841.A98D624F6C39@drugs.dv.isc.org> <279CABEB-4DEE-45C7-8CF2-8C34EAC3C214@fugue.com> <20120913035407.BBA7A24F7C84@drugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1486) Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Unicast DNS within the Homenet? 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, 13 Sep 2012 12:54:41 -0000 On Sep 12, 2012, at 11:54 PM, Mark Andrews wrote: > MacOS already supports this so clearly someone at Apple thinks > "there is a need".=20 No, MacOS doesn't support this. MacOS supports DynDNS-like = functionality, not roaming via DNS. And it supports it in the sense = that geeks can make it work, not in the sense that regular end users can = make it work. The necessary enabling work to make this usable is far = beyond what Apple is doing. Also beyond what Microsoft is doing. It's not hard, and if there's demand, I'm sure the work will get done. = As I said earlier, I don't oppose putting support for it into a spec, if = it can be done cleanly. But I don't think we'll see widespread = implementation anytime soon. From joelja@bogus.com Thu Sep 13 09:27: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 E248421F84F8 for ; Thu, 13 Sep 2012 09:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 Quobtz3lz5Or for ; Thu, 13 Sep 2012 09:27:48 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 6A1CE21F8533 for ; Thu, 13 Sep 2012 09:27:48 -0700 (PDT) Received: from joels-MacBook-Air.local (host-64-47-153-50.masergy.com [64.47.153.50]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q8DGREjj071900 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 13 Sep 2012 16:27:14 GMT (envelope-from joelja@bogus.com) Message-ID: <5052095C.7000102@bogus.com> Date: Thu, 13 Sep 2012 09:27:08 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120821 Thunderbird/15.0 MIME-Version: 1.0 To: Ray Hunter References: <47437C06-FB3D-41AB-ADB9-01A4091640E1@nominet.org.uk> <9466256C-546F-4EEE-9F94-CBF0C4E5967C@apple.com> <504F4210.9040700@mtcc.com> <0EBBAAF8-CF07-45B8-897C-C4CC69CC57F7@fugue.com> <50502E87.6030402@globis.net> <20120913010202.6A24D24F6237@drugs.dv.isc.org> <505170B7.1070505@globis.net> In-Reply-To: <505170B7.1070505@globis.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Thu, 13 Sep 2012 16:27:16 +0000 (UTC) Cc: Kerry Lynn , Mark Andrews , Michael Thomas , Ted Lemon , Ray Bellis , james woodyatt , "homenet@ietf.org Group" Subject: Re: [homenet] Unicast DNS within the Homenet? 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, 13 Sep 2012 16:27:50 -0000 On 9/12/12 10:35 PM, Ray Hunter wrote: > Fair counter point to my suggestion. Enterprises don't generally put > laptops in public viewable DNS. > > Isn't your requirement to support highly mobile devices a good reason > to avoid mDNS wherever possible? MDNS has a purpose, which is to locate on-link resources. particularly if a network is adhoc or ephemeral it seems like the appropriate tool for that. two devices forming an adjacency may have no other network. > [mDNS being link local specific, and any extensions/gateways from mDNS > to unicast DNS will also be local network specific, so your favourite > coffee shop network may not support them] > > regards, > RayH >> Mark Andrews >> 13 September 2012 03:02 >> >> Note updating DNS involves both FORWARD and REVERSE entries and the >> solutions can be different. >> >> My machines have names. Those names don't change as I move around >> the world. Random DHCP servers at coffee shops DO NOT have the >> ability to update the DNS entries for those names. They do have the >> authority to update the PTR records in in-addr.arpa and ip6.arpa >> namespaces. >> >> >> ------------------------------------------------------------------------ > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > From v6ops@globis.net Thu Sep 13 09:50: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 EB0E321F84D8 for ; Thu, 13 Sep 2012 09:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.135, 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 GfQEkiM+cn3f for ; Thu, 13 Sep 2012 09:50:35 -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 7ABF621F84CD for ; Thu, 13 Sep 2012 09:50:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 5255B8700E3; Thu, 13 Sep 2012 18:50:18 +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 G78V5hFs1xos; Thu, 13 Sep 2012 18:49:48 +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 8EFFF870056; Thu, 13 Sep 2012 18:49:48 +0200 (CEST) Message-ID: <50520EA6.2090606@globis.net> Date: Thu, 13 Sep 2012 18:49:42 +0200 From: Ray Hunter User-Agent: Postbox 3.0.4 (Macintosh/20120616) MIME-Version: 1.0 To: joel jaeggli References: <47437C06-FB3D-41AB-ADB9-01A4091640E1@nominet.org.uk> <9466256C-546F-4EEE-9F94-CBF0C4E5967C@apple.com> <504F4210.9040700@mtcc.com> <0EBBAAF8-CF07-45B8-897C-C4CC69CC57F7@fugue.com> <50502E87.6030402@globis.net> <20120913010202.6A24D24F6237@drugs.dv.isc.org> <505170B7.1070505@globis.net> <5052095C.7000102@bogus.com> In-Reply-To: <5052095C.7000102@bogus.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Kerry Lynn , Mark Andrews , Michael Thomas , Ted Lemon , Ray Bellis , james woodyatt , "homenet@ietf.org Group" Subject: Re: [homenet] Unicast DNS within the Homenet? 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, 13 Sep 2012 16:50:36 -0000 Sure, but the scope of this discussion is name resolution in Homenet, where there is always at least 1 router present. So these two devices could always use unicast to reach a rendezvous point. What devices do on other ephemeral ad hoc networks is out of scope. > joel jaeggli > 13 September 2012 18:27 > On 9/12/12 10:35 PM, Ray Hunter wrote: >> Fair counter point to my suggestion. Enterprises don't generally put >> laptops in public viewable DNS. >> >> Isn't your requirement to support highly mobile devices a good reason >> to avoid mDNS wherever possible? > MDNS has a purpose, which is to locate on-link resources. particularly > if a network is adhoc or ephemeral it seems like the appropriate tool > for that. two devices forming an adjacency may have no other network. > >> [mDNS being link local specific, and any extensions/gateways from >> mDNS to unicast DNS will also be local network specific, so your >> favourite coffee shop network may not support them] >> >> regards, >> RayH >>> Mark Andrews >>> 13 September 2012 03:02 >>> >>> Note updating DNS involves both FORWARD and REVERSE entries and the >>> solutions can be different. >>> >>> My machines have names. Those names don't change as I move around >>> the world. Random DHCP servers at coffee shops DO NOT have the >>> ability to update the DNS entries for those names. They do have the >>> authority to update the PTR records in in-addr.arpa and ip6.arpa >>> namespaces. >>> >>> >>> ------------------------------------------------------------------------ >>> >> >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet >> > > Ray Hunter > 13 September 2012 07:35 > Fair counter point to my suggestion. Enterprises don't generally put > laptops in public viewable DNS. > > Isn't your requirement to support highly mobile devices a good reason > to avoid mDNS wherever possible? > > [mDNS being link local specific, and any extensions/gateways from mDNS > to unicast DNS will also be local network specific, so your favourite > coffee shop network may not support them] > > regards, > RayH > > Mark Andrews > 13 September 2012 03:02 > > Note updating DNS involves both FORWARD and REVERSE entries and the > solutions can be different. > > My machines have names. Those names don't change as I move around > the world. Random DHCP servers at coffee shops DO NOT have the > ability to update the DNS entries for those names. They do have the > authority to update the PTR records in in-addr.arpa and ip6.arpa > namespaces. > > Machines start off with mDNS to avoid bootstrap problems. They > then have the ability to get a TSIG using TKEY signed with a > administrators TSIG (think Username/Password pair) for the forward > zone. This will be stored in non-volitile storage on the master > nameserver and on the client. Once the client has the TSIG key it > uses that to update its own forward entries. > > Machines register PTR records in the reverse zones using TCP as the > authenticator in the reverse zone unless there is a DHCP option > that says to use the DHCP server to relay the PTR record update. > > Ted Lemon > 12 September 2012 14:36 > > Two reasons. First, there's strong opposition to this, and so it will > never happen, whether it is the right idea or not (I don't think it's > particularly the right idea, although I'm not vehemently opposed to it > either). Secondly, it precludes the use of CGA by hosts. > > Ray Hunter > 12 September 2012 08:41 > Ted, respect your DHCP/DNS knowledge, but if we need a DHCP server > anyway in Homenet, why don't we go for the classic enterprise set up > that has run for years for IPv4, rather than trying to shoe horn > locally assigned SLAAC addresses into global DNS? > > It's not as though you can buy any piece of domestic networking > equipment today that does not support DHCPv4, so why not DHCPv6? > > So we'd have: > Homenet router <-> ISP = DHCP-PD to learn prefixes [existing] > in Homenet prefix allocation & distribution [work in progress] > DHCPv6 from the Homenet router to the ISP could be extended to > communicate any ISP DNS domain settings to the Homenet [gap] > elect/configure a unicast DNS server for Homenet [gap] > run standard unicast DNS [existing] > elect/configure a DHCPv6 server for use within Homenet [gap] > The routers that are acting as clients for DHCP-PD would seem good > candidates. > run standard DHCPv6 server on local Homenet router[existing] > configure DHCPv6 relay per Homenet router to point to Homenet DHCPv6 > server[existing standard, although autoconfig is a gap for the > election process] > use DHCPv6 server to update DNS content using RFC 2316 Dynamic DNS > update on behalf of end clients [existing] > client -> Homenet router RFC 3315 DHCPv6 based address configuration, > and standard unicast DNS [existing] > > Then the client only needs to do stuff that is already incorporated in > any operating system used in business. > > Or is this stateless /stateful war still too fresh in the collective > IETF memory? > > > ------------------------------------------------------------------------ From mike@mtcc.com Thu Sep 13 10:12:58 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 589F421F8564 for ; Thu, 13 Sep 2012 10:12:58 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pakh8TGsT9et for ; Thu, 13 Sep 2012 10:12:57 -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 B908021F8552 for ; Thu, 13 Sep 2012 10:12:57 -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 q8DHCP6X018652 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 13 Sep 2012 10:12:27 -0700 Message-ID: <505213F9.1050302@mtcc.com> Date: Thu, 13 Sep 2012 10:12:25 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Ted Lemon References: <47437C06-FB3D-41AB-ADB9-01A4091640E1@nominet.org.uk> <9466256C-546F-4EEE-9F94-CBF0C4E5967C@apple.com> <504F4210.9040700@mtcc.com> <0EBBAAF8-CF07-45B8-897C-C4CC69CC57F7@fugue.com> <50502E87.6030402@globis.net> <20120913010202.6A24D24F6237@drugs.dv.isc.org> <7E23E81A-9DAA-45AC-A577-3B0574E1DE1F@fugue.com> In-Reply-To: <7E23E81A-9DAA-45AC-A577-3B0574E1DE1F@fugue.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=964; t=1347556349; x=1348420349; 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]=20Unicast=20DNS=20within=20th e=20Homenet? |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=9yPC8+oPTby/6OTA14SdzD4ikn2P/nMfdOFGKQBuGd8=; b=qz6fFJ5HvvhPC197oH/WTd/o58q+t5KoUigsy0ZMj6k6YmaKumVUSeCvHC tg1NXhgcqs5CU7dg9fl2HWaL+FruNh9xrsB9kQ29/BWTdpgdYxu4evcXlKFt iW8z/LVyBRfLMwa2vc43xe5gawRylwnaJg9WBBLsrgFNa7U7YFAGs=; 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 , Mark Andrews , Ray Bellis , Ray Hunter , james woodyatt , "homenet@ietf.org Group" Subject: Re: [homenet] Unicast DNS within the Homenet? 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, 13 Sep 2012 17:12:58 -0000 On 09/12/2012 06:57 PM, Ted Lemon wrote: > On Sep 12, 2012, at 9:02 PM, Mark Andrews wrote: >> My machines have names. Those names don't change as I move around >> the world. Random DHCP servers at coffee shops DO NOT have the >> ability to update the DNS entries for those names. They do have the >> authority to update the PTR records in in-addr.arpa and ip6.arpa >> namespaces. > We're not talking about mobile IP here—we''re talking about naming in the homenet. The technology has existed for over a decade to do what you describe with DHCP and DDNS in IPv4, but AFAIK nobody uses it, for two reasons: one, I don't think it actually serves a real need, and two, it requires geek skills to set up, which most people don't have. But the second point is really a footnote to the first. > Suppose the real need would be to have a viable way to get rid of putting raw IP addresses in upper level protocols? Ie, SDP, etc? Mike From daveoran@orandom.net Thu Sep 13 13:16: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 BA7CA21F859E for ; Thu, 13 Sep 2012 13:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 1jFvw2jEl6Xc for ; Thu, 13 Sep 2012 13:16:00 -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 8D52621F8595 for ; Thu, 13 Sep 2012 13:16:00 -0700 (PDT) Received: from stealth-10-32-245-146.cisco.com (c-66-31-41-8.hsd1.ma.comcast.net [66.31.41.8]) (authenticated bits=0) by spark.crystalorb.net (8.14.3/8.14.3/Debian-9.4) with ESMTP id q8DKFXbt016527 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 13 Sep 2012 13:15:34 -0700 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: David R Oran In-Reply-To: <505213F9.1050302@mtcc.com> Date: Thu, 13 Sep 2012 16:15:27 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <633E18BC-F9E0-46FE-A900-AE9B2DBC9ADD@orandom.net> References: <47437C06-FB3D-41AB-ADB9-01A4091640E1@nominet.org.uk> <9466256C-546F-4EEE-9F94-CBF0C4E5967C@apple.com> <504F4210.9040700@mtcc.com> <0EBBAAF8-CF07-45B8-897C-C4CC69CC57F7@fugue.com> <50502E87.6030402@globis.net> <20120913010202.6A24D24F6237@drugs.dv.isc.org> <7E23E81A-9DAA-45AC-A577-3B0574E1DE1F@fugue.com> <505213F9.1050302@mtcc.com> To: Michael Thomas X-Mailer: Apple Mail (2.1498) Cc: Kerry Lynn , Mark Andrews , Ted Lemon , Ray Bellis , Ray Hunter , james woodyatt , "homenet@ietf.org Group" Subject: Re: [homenet] Unicast DNS within the Homenet? 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, 13 Sep 2012 20:16:01 -0000 On Sep 13, 2012, at 1:12 PM, Michael Thomas wrote: > On 09/12/2012 06:57 PM, Ted Lemon wrote: >> On Sep 12, 2012, at 9:02 PM, Mark Andrews wrote: >>> My machines have names. Those names don't change as I move around >>> the world. Random DHCP servers at coffee shops DO NOT have the >>> ability to update the DNS entries for those names. They do have the >>> authority to update the PTR records in in-addr.arpa and ip6.arpa >>> namespaces. >> We're not talking about mobile IP here=97we''re talking about naming = in the homenet. The technology has existed for over a decade to do = what you describe with DHCP and DDNS in IPv4, but AFAIK nobody uses it, = for two reasons: one, I don't think it actually serves a real need, and = two, it requires geek skills to set up, which most people don't have. = But the second point is really a footnote to the first. >>=20 >=20 > Suppose the real need would be to have a viable way to get rid of > putting raw IP addresses in upper level protocols? Ie, SDP, etc? >=20 That is a much broader architectural discussion than just DNS versus = other naming systems. The whole question of how and whether A can tell B = in an application protocol that he ought to talk to X in an independent = communication and whether the expectation is that X=3DA can be made = better, worse or just different when X is a name versus an address. I suggest we not talk about it - we risk ultimate regression to Godwin's = Law. The=20 > Mike > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From curtis@occnc.com Thu Sep 13 20:43: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 7B24621F86B9 for ; Thu, 13 Sep 2012 20:43:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LmhuN1yrjfXr for ; Thu, 13 Sep 2012 20:43:51 -0700 (PDT) Received: from gateway1.orleans.occnc.com (gateway1.orleans.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id DD8F221F851B for ; Thu, 13 Sep 2012 20:43:50 -0700 (PDT) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id q8E3hErm049688; Thu, 13 Sep 2012 23:43:16 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201209140343.q8E3hErm049688@gateway1.orleans.occnc.com> To: Ted Lemon From: Curtis Villamizar In-reply-to: Your message of "Wed, 12 Sep 2012 08:36:54 EDT." Date: Thu, 13 Sep 2012 23:43:14 -0400 Cc: Kerry Lynn , Michael Thomas , Ray Bellis , Ray Hunter , james woodyatt , "homenet@ietf.org Group" Subject: Re: [homenet] Unicast DNS within the Homenet? 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: Fri, 14 Sep 2012 03:43:51 -0000 In message Ted Lemon writes: > On Sep 12, 2012, at 2:41 AM, Ray Hunter wrote: > > > Ted, respect your DHCP/DNS knowledge, but if we need a DHCP server > > anyway in Homenet, why don't we go for the classic enterprise set up > > that has run for years for IPv4, rather than trying to shoe horn > > locally assigned SLAAC addresses into global DNS? > > Two reasons. First, there's strong opposition to this, and so it will > never happen, whether it is the right idea or not (I don't think it's > particularly the right idea, although I'm not vehemently opposed to it > either). Secondly, it precludes the use of CGA by hosts. Not using SLAAC does not preclude the use of CGA (RFC3971). The host can pick its own address with DHCP and use INFORM. It won't stop the host from using CGA or SEND (secure ND, RFC3972). Not that I think very highly of CGA as a security measure to start with but it could save a TCP RST on a TCP session running a protocol secured at the application layer and is lighter weight than IPSEC. That CGA was proposed in the first place is further proof that 128 bits in IPv6 addresses was pure folly. Unfortunately that decision dates all the way back to around 1995 and the huge addresses has been one reason IPv6 has been so slow to catch on. CGA tells us that the bottom 64 bits serves no purpose so we might as well use it for something else. The Flow ID field is another useless wart. Curtis From curtis@occnc.com Thu Sep 13 21:29:09 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64B1221F86F2 for ; Thu, 13 Sep 2012 21:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ib1Tq6atrSat for ; Thu, 13 Sep 2012 21:29:08 -0700 (PDT) Received: from gateway1.orleans.occnc.com (gateway1.orleans.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 4355B21F86F1 for ; Thu, 13 Sep 2012 21:29:03 -0700 (PDT) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id q8E4SclX049977; Fri, 14 Sep 2012 00:28:39 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201209140428.q8E4SclX049977@gateway1.orleans.occnc.com> To: Ted Lemon From: Curtis Villamizar In-reply-to: Your message of "Wed, 12 Sep 2012 21:57:09 EDT." <7E23E81A-9DAA-45AC-A577-3B0574E1DE1F@fugue.com> Date: Fri, 14 Sep 2012 00:28:38 -0400 Cc: Kerry Lynn , Mark Andrews , Michael Thomas , Ray Bellis , Ray Hunter , james woodyatt , "homenet@ietf.org Group" Subject: Re: [homenet] Unicast DNS within the Homenet? 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: Fri, 14 Sep 2012 04:29:09 -0000 In message <7E23E81A-9DAA-45AC-A577-3B0574E1DE1F@fugue.com> Ted Lemon writes: > On Sep 12, 2012, at 9:02 PM, Mark Andrews wrote: > > My machines have names. Those names don't change as I move around > > the world. Random DHCP servers at coffee shops DO NOT have the > > ability to update the DNS entries for those names. They do have the > > authority to update the PTR records in in-addr.arpa and ip6.arpa > > namespaces. > > We're not talking about mobile IP here—we''re talking about naming in > the homenet. The technology has existed for over a decade to do what > you describe with DHCP and DDNS in IPv4, but AFAIK nobody uses it, for > two reasons: one, I don't think it actually serves a real need, and > two, it requires geek skills to set up, which most people don't have. > But the second point is really a footnote to the first. DHCP and DDNS is used in enterprise and not for mobility, except to some extent mobility within the enterprise (laptops wandering to conference rooms). For anything that offers a service, meaning anything useful to connect to, DDNS is used so that if IT rearranges the wired ethernet, the server automagically has the same name but shows up somewhere else. In a past life IT tried to get me to do this with a CVS/SVN server but their DDNS didn't work enough times that I got them to go back to static entries. You can do things like direct SIP to a laptop with this and SIP URLs rather than (the far more common) B2BUA. > There's a draft in the DHC working group for setting up the reverse > zone... Did you mean: draft-lemon-dhc-dns-pd-01 Populating the DNS Reverse Tree for DHCP Delegated Prefixes Earlier in this thread you said: > > Ted, respect your DHCP/DNS knowledge, but if we need a DHCP server > > anyway in Homenet, why don't we go for the classic enterprise set up > > that has run for years for IPv4, rather than trying to shoe horn > > locally assigned SLAAC addresses i nto global DNS? > > Two reasons. First, there's strong opposition to this, and so it will > never happen, whether it is the right idea or not (I don't think it's > particularly the right idea, although I'm not vehemently opposed to it > either). Secondly, it precludes the use of CGA by hosts. There is also draft-ietf-dhc-cga-config-dhcpv6-02 Configuring Cryptographically Generated Addresses (CGA) using DHCPv6 which is where I wondered why you said that CGA could not be used and maybe I missed something. In your opinion CGA cannot be used if ... SLAAC is not used? ... DHCPv6 is used? ... something else? Since you made that statement, exactly what did you means. Curtis From curtis@occnc.com Thu Sep 13 22:00: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 B3A4721F86B9 for ; Thu, 13 Sep 2012 22:00:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.608 X-Spam-Level: X-Spam-Status: No, score=-2.608 tagged_above=-999 required=5 tests=[AWL=-0.008, 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 pGe+HOKJFmgP for ; Thu, 13 Sep 2012 22:00:14 -0700 (PDT) Received: from gateway1.orleans.occnc.com (gateway1.orleans.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 1743321F8621 for ; Thu, 13 Sep 2012 22:00:13 -0700 (PDT) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id q8E4xflQ050151; Fri, 14 Sep 2012 00:59:42 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201209140459.q8E4xflQ050151@gateway1.orleans.occnc.com> To: Mark Andrews From: Curtis Villamizar In-reply-to: Your message of "Thu, 13 Sep 2012 12:28:40 +1000." <20120913022841.A98D624F6C39@drugs.dv.isc.org> Date: Fri, 14 Sep 2012 00:59:41 -0400 Cc: Kerry Lynn , Michael Thomas , Ted Lemon , Ray Bellis , Ray Hunter , james woodyatt , "homenet@ietf.org Group" Subject: Re: [homenet] Unicast DNS within the Homenet? 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: Fri, 14 Sep 2012 05:00:14 -0000 In message <20120913022841.A98D624F6C39@drugs.dv.isc.org> Mark Andrews writes: [... trim ... net related to point below ...] > I have laptops that connect to the home net and then go walkabout. > I suspect a large percentage of homes have some equipment that moves > about. Those laptops still want to do things to the home net > occasionally. Devices on the home network want to push stuff to > those laptops occasionally. First thing is as soon as you walk from one AP to another, your channel changes and at least with Linux/BSD, nothing much happens. What should happen is wpa_supplicant should notify dhclient to try to renew the lease. If the APs are bridged, nothing need happen (but there will be more broadcast/multicast than need be). If you stepped into another subnet, then you'll need a new DHCP lease. I haven't tried this with a MAC. PCs don't seem to work unless you close the lid and suspend and then unsuspend. I don't think that with any OS right now (maybe android) you could walk down the street with an open laptop and switch from one business wifi to another (different subnets) and just have it work. OTOH - open wifi may not be common enough to try it on Main Street. OTOH if you shut down at home, go to the library or coffee shop, and start up, all is fine with any OS. Either the suspend/resume (when it doesn't hang the laptop) or shutdown/startup will trigger requesting a rebind and getting refused and getting a new lease. I've also run into the situation where a channel has a great signal but there is no DHCP server to be found. So my point is that 1) changing wireless channels should force an attempt to rebind, and 2) not getting any DHCP response or not getting all the required DHCP parameters should temporarily eliminate a channel from consideration and force roaming to another. I think homenet could recommend these actions in some document, though I don't see an existing document where it fits in. Curtis From mark@mbaugher.com Fri Sep 14 18:32: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 D351921F8569 for ; Fri, 14 Sep 2012 18:32:22 -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 JJBKQreFGBte for ; Fri, 14 Sep 2012 18:32:22 -0700 (PDT) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) by ietfa.amsl.com (Postfix) with ESMTP id 0B38121F855B for ; Fri, 14 Sep 2012 18:32:21 -0700 (PDT) Received: from sjc-mbaugher-8813.cisco.com (128-107-239-233.cisco.com [128.107.239.233]) (authenticated bits=0) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id q8C1EsLk056241 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 11 Sep 2012 18:14:56 -0700 (PDT) (envelope-from mark@mbaugher.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1278) From: Mark Baugher In-Reply-To: <201209112353.q8BNrcw5026314@gateway1.orleans.occnc.com> Date: Tue, 11 Sep 2012 18:14:49 -0700 Content-Transfer-Encoding: 7bit Message-Id: <4A2F8D5D-7C6F-4969-8FED-634A9DDF6DCE@mbaugher.com> References: <201209112353.q8BNrcw5026314@gateway1.orleans.occnc.com> To: "homenet@ietf.org Group" X-Mailer: Apple Mail (2.1278) Subject: Re: [homenet] Unicast DNS within the Homenet? 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, 15 Sep 2012 01:32:23 -0000 On Sep 11, 2012, at 4:53 PM, Curtis Villamizar wrote: > We had a similar discussion before and I pointed out that for security > some form of exchange of keys or certificates was needed. > > Having a factory configured root DNSSEC certificate gets one form of > trust anchor. The browser certificates provide another, possibly very > flawed forn of trust anchor. > > A means to create a local certificate and manually distribute this > could be the basis of a local trust anchor for local addresses and > names. > > For specific services it may be best to have certificates or keys > exchanged between client and server. In an unmanaged environment, some form of a ceremony is needed (http://eprint.iacr.org/2007/399.pdf), such as to prove locality and control. Mark From brian.e.carpenter@gmail.com Sat Sep 15 06:12: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 DE34B21F847D for ; Sat, 15 Sep 2012 06:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 0RmeXLLP+AkI for ; Sat, 15 Sep 2012 06:12:54 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id A652E21F8472 for ; Sat, 15 Sep 2012 06:12:54 -0700 (PDT) Received: by iabz21 with SMTP id z21so4611985iab.31 for ; Sat, 15 Sep 2012 06:12:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Vp6h30/UwEuCC/W5lqsZ5dXQVB7RtjDV+sqCfXmrQt0=; b=qYka89Au3lckhlQzf8TyCD9EytoZCmiURC8joURb5FUyQg692eqE1nQwqTFmC+CSLu 43tp2tu5ZdyFyMdgGFJV73KoJmBXh8JL+GsB5K52cvJsBTdqZc0susNp9PO8Coyo7+D9 A+eeTuGtLPuFfGYaWWEiFbtRtfRKuPnLPrYHRQ0GpT69Ef0CAHOzx47dAdId9NY99saF H8NhaxeIVR6LFpoLNMiyNdtT0mv5CtbnOjxDTxr1NDlG6FlbLBsylsq5B6B07EIIXWnQ KVfuV8WAR/pt9gZIx289hLtNOLS17nnwv1dYEuySQ1xuRDJH80J7D9C6Qg/sOBxX00zl WjRA== Received: by 10.50.154.164 with SMTP id vp4mr1747394igb.66.1347714769759; Sat, 15 Sep 2012 06:12:49 -0700 (PDT) Received: from [10.255.25.102] (50-76-68-140-static.hfc.comcastbusiness.net. [50.76.68.140]) by mx.google.com with ESMTPS id 10sm4563914igf.11.2012.09.15.06.12.46 (version=SSLv3 cipher=OTHER); Sat, 15 Sep 2012 06:12:48 -0700 (PDT) Message-ID: <50547EDA.4050002@gmail.com> Date: Sat, 15 Sep 2012 14:12:58 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: David R Oran References: <47437C06-FB3D-41AB-ADB9-01A4091640E1@nominet.org.uk> <9466256C-546F-4EEE-9F94-CBF0C4E5967C@apple.com> <504F4210.9040700@mtcc.com> <0EBBAAF8-CF07-45B8-897C-C4CC69CC57F7@fugue.com> <50502E87.6030402@globis.net> <20120913010202.6A24D24F6237@drugs.dv.isc.org> <7E23E81A-9DAA-45AC-A577-3B0574E1DE1F@fugue.com> <505213F9.1050302@mtcc.com> <633E18BC-F9E0-46FE-A900-AE9B2DBC9ADD@orandom.net> In-Reply-To: <633E18BC-F9E0-46FE-A900-AE9B2DBC9ADD@orandom.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Kerry Lynn , Mark Andrews , Michael Thomas , Ted Lemon , Ray Bellis , Ray Hunter , james woodyatt , "homenet@ietf.org Group" Subject: Re: [homenet] Unicast DNS within the Homenet? 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, 15 Sep 2012 13:12:56 -0000 On 13/09/2012 21:15, David R Oran wrote: > On Sep 13, 2012, at 1:12 PM, Michael Thomas wrote: >=20 >> On 09/12/2012 06:57 PM, Ted Lemon wrote: >>> On Sep 12, 2012, at 9:02 PM, Mark Andrews wrote: >>>> My machines have names. Those names don't change as I move around >>>> the world. Random DHCP servers at coffee shops DO NOT have the >>>> ability to update the DNS entries for those names. They do have the= >>>> authority to update the PTR records in in-addr.arpa and ip6.arpa >>>> namespaces. >>> We're not talking about mobile IP here=E2=80=94we''re talking about n= aming in the homenet. The technology has existed for over a decade to d= o what you describe with DHCP and DDNS in IPv4, but AFAIK nobody uses it,= for two reasons: one, I don't think it actually serves a real need, and = two, it requires geek skills to set up, which most people don't have. B= ut the second point is really a footnote to the first. >>> >> Suppose the real need would be to have a viable way to get rid of >> putting raw IP addresses in upper level protocols? Ie, SDP, etc? >> > That is a much broader architectural discussion than just DNS versus ot= her naming systems. The whole question of how and whether A can tell B in= an application protocol that he ought to talk to X in an independent com= munication and whether the expectation is that X=3DA can be made better, = worse or just different when X is a name versus an address. >=20 > I suggest we not talk about it - we risk ultimate regression to Godwin'= s Law. People who want to talk about it can still do so in the context of http://tools.ietf.org/html/draft-carpenter-referral-ps (Problem Statement for Referral) on the grobj@ietf.org list. It's been hard to get that conversation going, though. Brian From mellon@fugue.com Wed Sep 19 13:44: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 2810321E8049 for ; Wed, 19 Sep 2012 13:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.909 X-Spam-Level: X-Spam-Status: No, score=-0.909 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_96_XX=1.69] 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 rQ4HPv0OGioB for ; Wed, 19 Sep 2012 13:44:22 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 5ACC121E8045 for ; Wed, 19 Sep 2012 13:44:22 -0700 (PDT) Received: from [192.168.1.4] (164.sub-174-227-8.myvzw.com [174.227.8.164]) by toccata.fugue.com (Postfix) with ESMTPSA id 51AC62380969; Wed, 19 Sep 2012 16:43:55 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Ted Lemon In-Reply-To: <201209140343.q8E3hErm049688@gateway1.orleans.occnc.com> Date: Thu, 13 Sep 2012 23:51:58 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <633A609E-87D7-4C11-973C-22EA8244A18E@fugue.com> References: <201209140343.q8E3hErm049688@gateway1.orleans.occnc.com> To: curtis@occnc.com X-Mailer: Apple Mail (2.1486) Cc: Kerry Lynn , Michael Thomas , Ray Bellis , Ray Hunter , james woodyatt , "homenet@ietf.org Group" Subject: Re: [homenet] Unicast DNS within the Homenet? 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, 19 Sep 2012 20:44:23 -0000 On Sep 13, 2012, at 11:43 PM, Curtis Villamizar = wrote: > Not using SLAAC does not preclude the use of CGA (RFC3971). The host > can pick its own address with DHCP and use INFORM. It won't stop the > host from using CGA or SEND (secure ND, RFC3972). Curtis, go read the RFCs you're pontificating about and then get back to = us. Please? From mellon@fugue.com Wed Sep 19 13:45: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 5DD1A21E8049 for ; Wed, 19 Sep 2012 13:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.909 X-Spam-Level: X-Spam-Status: No, score=-0.909 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_96_XX=1.69] 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 NGcxdEaqOlVa for ; Wed, 19 Sep 2012 13:45:11 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id EBD5F21E8034 for ; Wed, 19 Sep 2012 13:45:10 -0700 (PDT) Received: from [192.168.1.4] (164.sub-174-227-8.myvzw.com [174.227.8.164]) by toccata.fugue.com (Postfix) with ESMTPSA id CA2B3238093B; Wed, 19 Sep 2012 16:44:15 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Ted Lemon In-Reply-To: <201209140428.q8E4SclX049977@gateway1.orleans.occnc.com> Date: Fri, 14 Sep 2012 11:00:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201209140428.q8E4SclX049977@gateway1.orleans.occnc.com> To: curtis@occnc.com X-Mailer: Apple Mail (2.1486) Cc: Kerry Lynn , Mark Andrews , Michael Thomas , Ray Bellis , Ray Hunter , james woodyatt , "homenet@ietf.org Group" Subject: Re: [homenet] Unicast DNS within the Homenet? 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, 19 Sep 2012 20:45:11 -0000 On Sep 14, 2012, at 12:28 AM, Curtis Villamizar = wrote: > You can do things like direct > SIP to a laptop with this and SIP URLs rather than (the far more > common) B2BUA. I would really like to see this happen, but we are so far from being = able to do this at the moment... >=20 >> There's a draft in the DHC working group for setting up the reverse >> zone... >=20 > Did you mean: >=20 > draft-lemon-dhc-dns-pd-01 > Populating the DNS Reverse Tree for DHCP Delegated Prefixes Yes. > draft-ietf-dhc-cga-config-dhcpv6-02 > Configuring Cryptographically Generated Addresses (CGA) using DHCPv6 >=20 > which is where I wondered why you said that CGA could not be used and > maybe I missed something. In your opinion CGA cannot be used if > ... SLAAC is not used? ... DHCPv6 is used? ... something else? > Since you made that statement, exactly what did you means. If your address is assigned by the DHCP server, it can't be a CGA = address, because the private key isn't private. The DHC working group = is working on a draft to allow addresses generated using SLAAC or CGA to = be registered to the DHCP server in a way that allows DHCP updates to = the DNS, either the forward and reverse zones, or just the reverse zone. = But this is new work, and hasn't been published as an RFC yet. The = relevant draft is here: = http://datatracker.ietf.org/doc/draft-ietf-dhc-addr-registration/ From mellon@fugue.com Wed Sep 19 13:48: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 8E1F021E8045 for ; Wed, 19 Sep 2012 13:48:48 -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 0hPFzLfxqU9K for ; Wed, 19 Sep 2012 13:48:48 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 2E5D021E8034 for ; Wed, 19 Sep 2012 13:48:48 -0700 (PDT) Received: from [192.168.1.4] (80.sub-70-192-0.myvzw.com [70.192.0.80]) by toccata.fugue.com (Postfix) with ESMTPSA id 48B02238093B; Wed, 19 Sep 2012 16:48:43 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Ted Lemon In-Reply-To: Date: Wed, 19 Sep 2012 16:48:41 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201209140428.q8E4SclX049977@gateway1.orleans.occnc.com> To: curtis@occnc.com X-Mailer: Apple Mail (2.1486) Cc: Kerry Lynn , Mark Andrews , Michael Thomas , Ray Bellis , Ray Hunter , james woodyatt , "homenet@ietf.org Group" Subject: Re: [homenet] Unicast DNS within the Homenet? 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, 19 Sep 2012 20:48:48 -0000 On Sep 14, 2012, at 11:00 AM, Ted Lemon wrote: > If your address is assigned by the DHCP server, it can't be a CGA = address, because the private key isn't private. The DHC working group = is working on a draft to allow addresses generated using SLAAC or CGA to = be registered to the DHCP server in a way that allows DHCP updates to = the DNS, either the forward and reverse zones, or just the reverse zone. = But this is new work, and hasn't been published as an RFC yet. The = relevant draft is here: = http://datatracker.ietf.org/doc/draft-ietf-dhc-addr-registration/ Sorry for the late barrage of messages in this discussion=97my mail = program was jammed up for some reason. From curtis@occnc.com Sat Sep 22 20:30: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 6B26221F8555 for ; Sat, 22 Sep 2012 20:30:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.008 X-Spam-Level: X-Spam-Status: No, score=-1.008 tagged_above=-999 required=5 tests=[AWL=-1.608, BAYES_50=0.001, J_CHICKENPOX_31=0.6, 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 JAeIyGkgiEuE for ; Sat, 22 Sep 2012 20:30:48 -0700 (PDT) Received: from gateway1.orleans.occnc.com (gateway1.orleans.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 7E58721F84E6 for ; Sat, 22 Sep 2012 20:30:47 -0700 (PDT) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id q8N3Uix6047290; Sat, 22 Sep 2012 23:30:45 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201209230330.q8N3Uix6047290@gateway1.orleans.occnc.com> To: homenet@ietf.org From: Curtis Villamizar Date: Sat, 22 Sep 2012 23:30:44 -0400 Cc: curtis@occnc.com Subject: [homenet] draft-ietf-homenet-arch-04 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, 23 Sep 2012 03:30:50 -0000 Tim, Jari, Anders, Ole, Jason, I hope this is an OK time for comments on this draft. I just spent some time going through draft-ietf-homenet-arch-04 and I also took the time to look through all the RFCs and drafts that it references, even most of the expired ones. I edited in some diffs to the xml2rfc source. Most of the diffs should be self explanitory, though I'm sure some will not be without controversy on the WG list. I left in some XML comments where either I wanted to explain a change, or I would like to see some discussion on list. The xml file is at http://www.ietf.org/id/draft-ietf-homenet-arch-04.xml The diffs are below. Hopefully we can all read unified diffs of an xml file. I'll also summarize some major points here. 1. Must be capable of self configuring but should allow manual config. 2. A few citations could stand to be removed. Some drafts are expired and don't look like they were entirely completed. Some of the expired drafts look good but just managed to expire. 3. I am proposing that we drop the "well known name" as a means to discover the border(s). This seems to me like a real bad idea. 4. In "Global addressability and elimination of NAT" (false-)security concerns about losing NAT are cited but no advantage to global addressability is cited. I think that is an oversight but didn't add text here. (yet) 5. In a few places I've pointed out that firewalls (and NAT and anti-virus) provide very ineffective security and we should be very up front about saying so, though we can acknowledge that in the absense of reasonably secure home products, we can't get rid of them just yet. 6. Proposals for IPv6-only MUST provide some accommodations for legacy IPv4 only hosts or plain vanilla DS hosts. I called this IPv4 fallback on an otherwise IPv6 only network. I split the bullet on NAT64/DNS64 into two. a. As I had pointed out on the list, doing DNS64 at the CE (or a router) will break any IPv4 only host. The DNS64 translation should be done at the host. The NAT64 can be done at the CE (or any willing router). b. The DS-Lite B4 can be done on the host as long as DHCPv6 tells the host that an AFTR is availalbe. If the CE gets the FQDN of an AFTR as a DHCPv6 client on the WAN side it can pass that along to hosts as a server on the DHCPv6 homenet side. The DS-Lite B4 capable host can tunnel to the AFTR and not make a DHCPv4 request (operate v6only). The plain DS and IPv4-only hosts can make DHCPv4 requests. If V4 packets arrive at the CE, the CE can act as a B4 if the provider gave a AFTR FQDN in the WAN side DHCPv6. 7. If some topology can casue things to be broken, then what the homenet WG specified is broken. Added some text on pathelogical cases. The only true pathological case is a loop in a set of repeaters if a routing protocol is used and switches either detect cycles or use IEEE spanning tree or link state protocols. 8. Cascading NATs are common. Added text as to why. 9. Questioned why we mention VLANs. An unsophisticated home user is not likely to be playing with VLANs. 10. Should we get rid of physical standard references? I think so. 11. Modified "bridge whenever possible" text. Also "Largest possible subnets" section title changed to "Largest practical subnets" for reasons given in comments. 12. This is sure to be controversial. I pointed out that using subnets longer than /64 is OK as long as they are not leaked into global routing. Please read the text and changes before exploding on this topic. It may be necessary to subnet a /64 if that is all a provider will give you and you need subnets. It does work and it is no more unnatural than subnetting a class-A network would be in 1990. It means using DHCPv6 and not using RA prefixes for GUA (otherwise SLAAC implementations would likely try to use the whole bottom 64). 13. There are a few minor wording changes, minor clarifications, etc. 14. There may be more fuss about confining interior routing within a border than needed. I added a paragraph that might help (or might not). 15. In the security section I added a subsection named "Marginal Effectiveness of NAT and Firewalls". (btw- Firewall horror story at bar BOF on request.) 16. Added "It has been suggested that Dynamic DNS could be made to operate in a zero-configuration mode using a locally significant root domain and with minimal configuration or using a DHCPv6 based (details to-be-defined) means of automated delegation populate a global DNS zone." Maybe a draft is needed on this but for now please discuss on list. 17. Suggest that any mechanism that is subnet-only has to be extended to site *or abandoned by the WG* rather than proxied. Old text said extended but not proxied (sic). 18. Updated references (one draft is now RFC, one individual draft is now WG draft, noted those that are expired). 19. Question on "ISPs renumber due to privacy laws". What's that all about? Curtis BTW- The file still compiles and I made some updates to the references section which means the entity defines up front are edited. I'm quite sure you'll want to pick and choose diffs or hand edit the changes you want back in. Hopefully you'll want something. :) --- draft-ietf-homenet-arch-04.xml.orig 2012-07-16 10:00:38.000000000 -0400 +++ draft-ietf-homenet-arch-04.xml 2012-09-22 22:06:24.000000000 -0400 @@ -4,13 +4,17 @@ + + + + @@ -52,8 +56,8 @@ - + @@ -202,8 +206,9 @@ which case such networks may use increasing numbers of subnets, and require methods for IPv6 prefixes to be delegated to those subnets. The assumption of this document is that the -homenet is as far as possible self-organising and self-configuring, -and is thus not pro-actively managed by the residential user. +homenet is as far as possible +capable of self-organising and self-configuring, +and is thus need not be pro-actively managed by the residential user. The @@ -258,6 +263,9 @@ "Advanced Security". Describes advanced security functions for a CER, as defined in , where the default inbound connection policy is generally "default allow". + CER: Customer Edge Router. A border router at the edge of the homenet. LLN: Low-power and lossy network. NAT: Network Address Translation. Typically referring to IPv4 @@ -283,10 +291,9 @@
-Service providers are deploying IPv6, content is becoming available on -IPv6 (accelerated recently by the World IPv6 Launch event) -and support for IPv6 is increasingly available in devices and -software used in the home. While + +While IPv6 resembles IPv4 in many ways, it changes address allocation principles, making multi-addressing the norm, and allowing direct IP addressability of home networking @@ -323,9 +330,14 @@ Documents that provide some more specific background and depth on this topic include: -, -, and -. +, +, and +. + + The addition of routing between subnets raises the issue of how to extend mechanisms such as service discovery which currently rely @@ -340,6 +352,10 @@ Here, there are a number of choices. These include an appropriate service discovery protocol, or the use of a well-known name, resolved by some local name service. + Both might have to deal with handling more than one router responding in multihomed environments. @@ -357,6 +373,9 @@ allowing every device on every link to be assigned a globally unique IPv6 address. + The end-to-end communication that is potentially enabled with IPv6 is on the one hand an incredible @@ -373,6 +392,12 @@ would only be used on private networks or the device itself doesn't have the computing power to apply the necessary security methods. + IPv6 networks may or may not have filters applied at their borders, i.e. at the homenet CER. @@ -498,11 +523,33 @@ should be considered in IPv6-only environments: -Ensuring there is a way to access content in the IPv4 Internet. This can +Ensuring there is a way to access content in the IPv4 Internet. + + +This can be arranged through incorporating NAT64 and DNS64 functionality in the home gateway router, for instance. Such features -are outside the scope of this document however, being CER functions. +are outside the scope of this document however, being CER functions. +Legacy IPv4-only hosts could not function in a network for which the +DNS server implements DNS64. Therefore a DNS64 NS may need to disable +DNS64 translation for DNS queries arriving via IPv4 transport. +This can also be arranged through use of +DS-Lite, with the DS-Lite +B4 implemented in the host and the DS-Lite AFTR implemented in the +CPE, or the AFTR FQDN passed from the CPE to the host if AFTR is +offerred by the service provider. + + + + DNS discovery mechanisms are enabled for IPv6. Both stateless DHCPv6 +It is desirable for mechanisms which enable IPv6-only host +operation, to also support IPv4 as a fallback for legacy devices and +support DHCPv4 for legacy IPv4 only hosts and for IPv6 DS devices +which fail to operate without IPv4 and DHCPv4. + @@ -551,7 +604,8 @@ expect the resulting network to operate. Significant manual configuration is rarely, if at all, possible, given the knowledge level of typical home users. Thus the network should, -as far as possible, be self-configuring. +as far as possible, be self-configuring. For the benefit of the +atypical more advanced user, manual configuration should be supported. The equipment also needs @@ -623,6 +677,17 @@ infrastructure to allow the rest to operate. In such cases, the user should ideally have some useful indication of the failure mode encountered. +There are no topology secenarios which could cause loss of +connectivity, except when the user +creates a physical island within the topology. Some potentially +pathological cases that can be created include bridging ports of a +router together, however this case can be detected and dealt with by +the router. Routing cycles within a topology are in a sense good in +that they offer redundancy. Bridging cyslces can be dangerous but are +also detectable when a switch learns the MAC of one of its interfaces +on another or runs a spanning tree or link state protocol. It is only +cycles using simple repeaters that are truly pathological. +
@@ -636,6 +701,14 @@ and private networks. +Cascading NATs are somewhat common in IPv4 home networks. Many +devices such as SIP devices and some streaming video devices have a +WAN side and LAN side Ethernet port and in their installation +instructions either recommend or insist on being the device closest to +the WAN for QoS reasons. A user may comply and string these together +resulting in two or three or potentially more cascaded IPv4 NAT. + + In general, the models described in and its successor RFC 6204-bis @@ -656,6 +729,9 @@ subnets, with no direct connectivity between them within the homenet. Isolation may be physical, or implemented via IEEE 802.1q VLANs. + Demarcation of the CER. The CER(s) may or may not be managed by the ISP. If the demarcation point is such that the customer can provide or manage the CER, its configuration must be simple. Both @@ -688,6 +764,23 @@ A separate discussion of physical infrastructures for homenets is included in and . + + In the following sections we give some examples of the types of @@ -707,7 +800,8 @@ topology itself may also be complex, and it may not be possible to assume a pure tree form, for instance (home users may plug routers together to form arbitrary topologies -including loops). +including cycles. +
@@ -863,7 +957,9 @@ A general recommendation is to follow the same topology for IPv6 as is used for IPv4, but not to use NAT. Thus there should be routed IPv6 where an IPv4 NAT is used, and where there is no NAT -there should be bridging if the link layer allows this. +routing or bridging may be used. Routing may have advantages over +bridging together high speed and lower speed shared media and bridging +may not be suitable for some media, such as ad-hoc mobile networks. In some cases IPv4 NAT @@ -925,12 +1021,14 @@ typically include . Applications may of course do different things, and this should not be precluded. + For the single CER Network Model C, multihoming may be offered by source routing at the CER. With multiple exit routers, the complexity rises. Given a packet with a source address on the network, the -packet must be routed to the proper egress to avoid BCP 38 +packet must be routed to the proper egress to avoid BCP 38 +() filtering at an ISP that did not delegate the prefix the address is chosen from. While the packet might not take an optimal path to the correct exit CER, the @@ -939,11 +1037,12 @@ that the packet is routed in the most efficient manner to the correct exit. + There are various potential approaches to this problem, one example being described in -. +. Another is discussed in , which explores support for source routing throughout the homenet. This approach would however likely require relatively significant @@ -951,6 +1050,8 @@ given the source address. Such changes should preferably be minimised. + There are some other multihoming considerations for homenet scenarios. First, it may be the case that @@ -967,6 +1068,7 @@ While we should not specifically target walled garden multihoming as a principal goal, it should not be precluded. + Host-based methods such @@ -1049,7 +1151,7 @@
-
+
Today's IPv4 home networks generally have a single subnet, and early dual-stack deployments have a single congruent IPv6 subnet, @@ -1063,9 +1165,11 @@ routers and thus need multiple subnets, for the reasons described earlier. As part of the self-organisation of the network, the homenet should subdivide -itself to the largest possible subnets that can be constructed within +itself to the largest practical subnets that can be constructed within the constraints of link layer mechanisms, bridging, physical -connectivity, and policy. +connectivity, policy, and where applicable performance or other +criteria. For example, bridging a busy GbE subnet and a wireless +subnet together may impact wireless performance. While it may be desirable to maximise the chance of link-local @@ -1073,6 +1177,15 @@ multi-subnet home networks are inevitable, so their support must be included. +
@@ -1109,6 +1222,31 @@ homenet will need to adapt to the prefixes made available to it through the prefix delegation method used by its upstream ISP. + +It is important to note that for the purpose of a homenet, a /64 +prefix is subdividable. specifically states +"Subnet numbers must be assumed to come from the network part. This +is not to preclude routing protocols such as IS-IS level 1 +(intra-area) routing, which routes individual host addresses, but says +that it may not be depended upon in the world outside that zone." +Prefixes longer than /64 are not globally routable but may be used by +protocols such as IS-IS or OSPF to subdivide a /64. Subdividing a /64 +effectively requires a managed address space, disallowing allocation +within that /64 though SLAAC and disallowing +any technique which requires the use of the full lower 64 bits such as +CGA . + + + +If faced with allocation of a /64 prefix, or a prefix that is too +short to support a /64 for each subnet it may be necessary to +subdivide one or more /64. This need may arise if some providers +refuse to allocate anything but a /64 to home users, small office +users, or very small businesses. The need to get the network running +may have to be weighed against other needs such as CGA. + +
@@ -1123,7 +1261,8 @@ and thus make no assumptions about the stability of the prefix received from an ISP, or the length of the prefix that may be offered. However, if only a /64 is offered by the ISP, the homenet may be -severely constrained, or even unable to function. +severely constrained, or even unable to function if the /64 cannot be +subdivided due to conflicting requirements (such as CGA). The internal operation of the home network should also not depend on @@ -1142,6 +1281,12 @@ their prefix pool) changing. It is not expected that ISPs will support Provider Independent (PI) addressing for general residential homenets. + When an ISP needs to restructure and in doing so renumber its customer homenets, "flash" renumbering is likely to be imposed. This implies a need @@ -1154,6 +1299,8 @@ is an extended version of an initial numbering process, the difference between flash renumbering and an initial "cold start" is the need to provide service continuity. +The depricated addresses would remain usable within the homenet as +described in . There may be cases where local law means some ISPs are required to change @@ -1177,6 +1324,11 @@ The introduction of any new homenet protocols should not make any form of renumbering any more complex than it already is. +
@@ -1213,6 +1365,30 @@ scope through filtering at the border(s) of the homenet, as described in RFC 6092. + +If a routing protocol (or static routing) is not used, then ULA or GUA +connectivity across subnets cannot occur. ULA connectivity requires +that host routes (IPv6 /128 routes) be used. In a very large network +this would pose a scaling issue. Homenets should be sufficiently +small that scalability is not at all an issue, even is the absence of +the route aggregation afforded by GUA subnet routes. An interior +routing protocol adjacency (IS-IS or OSPF) should not be attempted by +default on a provider interface, and will generally require a shared +secret with the provider, implying a need for configuration. If such +an adjacency is configured, route summarization of GUA routes is +required and no ULA routes should be advertised to the provider. Any +sensible provider will provide route filters on their end. More +likely no routing protocol adjacency will exist between the homenet CE +and the provider. For medium sized businesses (not a homenet) a BGP +adjacency might be used, but still no OSPF or IS-IS adjacency. +Similarly the provider would pay no attention to distance vector +routing protocol information erroneously sent from the homenet. The +homenet interior routing information would therefore always be +confined to the homenet. + +
@@ -1230,7 +1406,8 @@ . Then each subnet in the homenet should receive a prefix from within the ISP-provided prefix(es). The ISP should only see the aggregate from -the homenet, and not single /64 prefixes allocated within the homenet. +the homenet, and not single /64 (or longer) prefixes allocated within +the homenet. Delegation should be autonomous, and not assume a flat or @@ -1281,14 +1458,18 @@ Several proposals have been made for prefix delegation within a homenet. One group of proposals is based on DHCPv6 PD, as described in -, -, +, +, and . The other uses OSPFv3, as described in . More detailed analysis of these approaches needs to be made against the requirements/principles described above. +
@@ -1385,6 +1566,8 @@ evaluations of common routing protocols made against the type of requirements described above. +
@@ -1406,10 +1589,41 @@ to be able to operate securely, end-to-end where required, but also be robust against malicious traffic direct towards them. We simply note at -this point that software on home devices will have an increase in +this point that software on home devices may have an increase in security if it allows its software to be updated regularly. +
+ +Security by way of obscurity (address translation) or through +firewalls (filtering) is at best marginally effective. The very poor +security track record of home computer, home networking and business +PC computers and networking is testomony to its ineffectiveness. A +compromise behind the firewall of any device exposes all others, +making an entire network that relies on obscurity or a firewall as +vulnerable as the most insecure device on the private side of the +network. + + +However, given home network products with very poor security, putting +a firewall in place does provide some protection, even if only +marginally effective. IPv6 global reachability may increase the need +to solve the underlying problem of certain insecure home and business +computer and network products. The use of firewalls today, whether a +good practice or not, is common practice and whatever protection +afforded, even if marginally effective, must not be lost. + + +
+
An IPv6-based home network architecture should embrace @@ -1465,6 +1679,8 @@ to be configured on a CER. Such methods should be able to be automatically updating. +
@@ -1577,7 +1793,11 @@ There are naming protocols that are designed to be configured and operate Internet-wide, like unicast-based DNS, but also protocols that are designed for zero-configuration local environments, like -mDNS. Consideration should be made for how these interact with each +mDNS. It has been suggested that Dynamic DNS could be made to operate +in a zero-configuration mode using a locally significant root domain +and with minimal configuration or using a DHCPv6 based (details +to-be-defined) means of automated delegation populate a global DNS +zone. Consideration should be made for how these interact with each other in a homenet scenario. @@ -1634,6 +1854,8 @@ to multicast service discovery requests. Those same parts of the network may have less capacity for multicast traffic that may be flooded from other parts of the network. + In general, message utilisation should be efficient considering the network technologies the service may need to operate over. @@ -1650,7 +1872,7 @@ Current service discovery protocols are generally aimed at single -subnets. If service discovery is to operate across the an entire +subnets. If service discovery is to operate across an entire homenet, by adopting an approach like that proposed as Extended mDNS (xmDNS) , then support may be required for IPv6 multicast across the scope of the @@ -1682,12 +1904,14 @@ The homenet architecture proposes that any existing protocols that are designed to only work within a subnet should be extended -to work across subnets, rather than defining proxy capabilities +to work across subnets or not used by homenet, +rather than defining proxy capabilities for each of those functions. However, while it is desirable to extend protocols to site scope operation rather than providing proxy functions on subnet boundaries, the reality is that until all hosts can use site-scope discovery protocols, -existing link-local protocols would need to be proxied anyway. +existing link-local protocols would need to be proxied anyway or other +solutions found which are not link local in scope. Some protocols already have proxy functions defined and in use, e.g. DHCPv6 relays, in which case those protocols would be expected to @@ -1812,10 +2036,14 @@ &rfc1918; + &rfc2462; &rfc2475; &rfc2775; + &rfc2827; &rfc3022; + &rfc3177; &rfc3646; + &rfc3972; &rfc4192; &rfc5533; &rfc5969; @@ -1826,22 +2054,26 @@ &rfc6296; &rfc6333; &rfc6555; - &I-D.baker-fun-multi-router; - &I-D.lynn-homenet-site-mdns; - &I-D.townsley-troan-ipv6-ce-transitioning; - &I-D.baker-fun-routing-class; - &I-D.howard-homenet-routing-comparison; - &I-D.herbst-v6ops-cpeenhancements; - &I-D.vyncke-advanced-ipv6-security; - &I-D.ietf-6man-rfc3484bis; - &I-D.v6ops-multihoming-without-ipv6nat; - &I-D.baker-homenet-prefix-assignment; + &I-D.baker-fun-multi-router; + &I-D.lynn-homenet-site-mdns; + &I-D.townsley-troan-ipv6-ce-transitioning; + &I-D.baker-fun-routing-class; + &I-D.howard-homenet-routing-comparison; + &I-D.herbst-v6ops-cpeenhancements; + &I-D.vyncke-advanced-ipv6-security; + &I-D.ietf-6man-rfc3484bis; + &I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat; + &I-D.baker-homenet-prefix-assignment; &I-D.arkko-homenet-prefix-assignment; &I-D.acee-ospf-ospfv3-autoconfig; - &I-D.ietf-pcp-base; - &I-D.hain-ipv6-ulac; - &I-D.chakrabarti-homenet-prefix-alloc; - &I-D.arkko-homenet-physical-standard; + &I-D.ietf-pcp-base; + &I-D.hain-ipv6-ulac; + &I-D.chakrabarti-homenet-prefix-alloc; + &I-D.arkko-homenet-physical-standard; + + @@ -1953,7 +2185,7 @@ Clarified simple and advanced security some more, and RFC 4864 and 6092. Stated that there should be just one secret key, if any are used at all. For multihoming, support multiple CERs but note that routing to the correct CER to avoid ISP filtering may not be optimal within the homenet. -Added some ISPs renumber due to privacy laws. +Added some ISPs renumber due to privacy laws. Removed extra repeated references to Simple Security. Removed some solution creep on RIOs/RAs. Load-balancing scenario added as to be supported. From jmh@joelhalpern.com Sat Sep 22 20:37: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 4D87E21F8587 for ; Sat, 22 Sep 2012 20:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.169 X-Spam-Level: X-Spam-Status: No, score=-102.169 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 IxZdgBSXoXpx for ; Sat, 22 Sep 2012 20:37:37 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 9486421F8581 for ; Sat, 22 Sep 2012 20:37:37 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 47C61557FEC for ; Sat, 22 Sep 2012 20:37:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 6D4041C00BD2; Sat, 22 Sep 2012 20:37:35 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.10.10.104] (pool-71-161-51-10.clppva.btas.verizon.net [71.161.51.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id CB9B11C00AA7; Sat, 22 Sep 2012 20:37:34 -0700 (PDT) Message-ID: <505E83F6.3030900@joelhalpern.com> Date: Sat, 22 Sep 2012 23:37:26 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: curtis@occnc.com References: <201209230330.q8N3Uix6047290@gateway1.orleans.occnc.com> In-Reply-To: <201209230330.q8N3Uix6047290@gateway1.orleans.occnc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org Subject: Re: [homenet] draft-ietf-homenet-arch-04 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Sep 2012 03:37:38 -0000 Since you invited flames... The argument on /64 as the longest prefix is not that it is magically unnatural. Rather, it is that there are a number of current and evolving protocols that depend upon that /64. The obvious example is that SLAAC does not work if subnets are longer than /64. The rules in this regard are written into approved RFCs. If homenet wants to change that, it really needs to go to 6man with a strong case. (for point-to-point inter-router links this was recently relaxed. At the same time, andy operator who insists on giving homes a /64 is being inappropriately restrictive. Homenet should say that, rather than trying to change the IPv6 architecture. Yours, Joel On 9/22/2012 11:30 PM, Curtis Villamizar wrote: > 12. This is sure to be controversial. I pointed out that using > subnets longer than /64 is OK as long as they are not leaked > into global routing. Please read the text and changes before > exploding on this topic. It may be necessary to subnet a /64 if > that is all a provider will give you and you need subnets. It > does work and it is no more unnatural than subnetting a class-A > network would be in 1990. It means using DHCPv6 and not using > RA prefixes for GUA (otherwise SLAAC implementations would > likely try to use the whole bottom 64). From curtis@occnc.com Sun Sep 23 16:09: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 224FE21F8522 for ; Sun, 23 Sep 2012 16:09:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[AWL=-0.637, BAYES_05=-1.11, 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 3qJHoNJH76lA for ; Sun, 23 Sep 2012 16:09:26 -0700 (PDT) Received: from gateway1.orleans.occnc.com (gateway1.orleans.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 6E9B121F851C for ; Sun, 23 Sep 2012 16:09:26 -0700 (PDT) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id q8NN9FlR056677; Sun, 23 Sep 2012 19:09:15 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201209232309.q8NN9FlR056677@gateway1.orleans.occnc.com> To: "Joel M. Halpern" From: Curtis Villamizar In-reply-to: Your message of "Sat, 22 Sep 2012 23:37:26 EDT." <505E83F6.3030900@joelhalpern.com> Date: Sun, 23 Sep 2012 19:09:15 -0400 Cc: homenet@ietf.org, curtis@occnc.com Subject: Re: [homenet] draft-ietf-homenet-arch-04 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, 23 Sep 2012 23:09:27 -0000 In message <505E83F6.3030900@joelhalpern.com> "Joel M. Halpern" writes: > Since you invited flames... > > The argument on /64 as the longest prefix is not that it is magically > unnatural. > Rather, it is that there are a number of current and evolving protocols > that depend upon that /64. The obvious example is that SLAAC does not > work if subnets are longer than /64. > > The rules in this regard are written into approved RFCs. If homenet > wants to change that, it really needs to go to 6man with a strong case. > (for point-to-point inter-router links this was recently relaxed. > > At the same time, andy operator who insists on giving homes a /64 is > being inappropriately restrictive. Homenet should say that, rather than > trying to change the IPv6 architecture. > > Yours, > Joel Joel, I don't consider your email a flame at all. Thanks for responding. SLAAC (which I am not at a fan of) won't work but DHCPv6 will so IMHO no loss. CGA also won't work but then again I've also never been a fan of security half measures. Yes anti-spoofing without prior exchange of a key is nice, but no reasonable authorization could be based on CGA without also exchanging some sort of key or cert and at that point the CGA as a public key is redundant. If SLAAC and CGA are the only things that break *and* providers do hand out prefixes that are too small, then /64 prefixes will have to be subdivided. So a question for you is what else if anything will break? I also understand that you are suggesting that this be taken to 6man. That is a good suggestion. Curtis > On 9/22/2012 11:30 PM, Curtis Villamizar wrote: > > 12. This is sure to be controversial. I pointed out that using > > subnets longer than /64 is OK as long as they are not leaked > > into global routing. Please read the text and changes before > > exploding on this topic. It may be necessary to subnet a /64 if > > that is all a provider will give you and you need subnets. It > > does work and it is no more unnatural than subnetting a class-A > > network would be in 1990. It means using DHCPv6 and not using > > RA prefixes for GUA (otherwise SLAAC implementations would > > likely try to use the whole bottom 64). From d.sturek@att.net Sun Sep 23 17:39: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 3D97E21F8550 for ; Sun, 23 Sep 2012 17:39: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x1-V0M+wbxCT for ; Sun, 23 Sep 2012 17:39:01 -0700 (PDT) Received: from nm1.bullet.mail.sp2.yahoo.com (nm1.bullet.mail.sp2.yahoo.com [98.139.91.71]) by ietfa.amsl.com (Postfix) with SMTP id BA46A21F8549 for ; Sun, 23 Sep 2012 17:39:01 -0700 (PDT) Received: from [98.139.91.68] by nm1.bullet.mail.sp2.yahoo.com with NNFMP; 24 Sep 2012 00:38:56 -0000 Received: from [66.94.237.115] by tm8.bullet.mail.sp2.yahoo.com with NNFMP; 24 Sep 2012 00:38:56 -0000 Received: from [127.0.0.1] by omp1020.access.mail.mud.yahoo.com with NNFMP; 24 Sep 2012 00:38:56 -0000 X-Yahoo-Newman-Id: 767691.99625.bm@omp1020.access.mail.mud.yahoo.com Received: (qmail 43528 invoked from network); 24 Sep 2012 00:38:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1348447136; bh=8yDWPQQux7G3Ezq21M+7nAaLW1u+AJUWd7dByFiVAkg=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=RXhchWf56ZPCEbYaOYaD+E5rGLYDaKbnV7zJ5/cXebVgD2P3R0nFT88rpPvWlmVJX5VdMaFnFMj1FuUfcYY6EBAW1NU7X6LYQtdTl7un4vTMcJuGiZZSQuGH2OxtBasnoIpNUE48ccVxQRaRJs8B6OqfNXK+C0RL9a8Z338KvV8= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: _Wk88D8VM1lXOOgQXketI6GTlkuNUNppFSb9MZ1itI6diCj T1QCRbvs8CmNAUtK9Iq4bHyynTKetD6jJl6WnLHaJ1Rutn1yFjvSNEksp0Gr 0Vb8Qh8kZtTYzaP4t3VSBvYgwd4wtOdoBkApvRg.G7H0ffILQ3bLdpPWar33 NqIcogvs5neteE3ghO0fre8nwb9EjqCwCcKTElFFtrwWzjG67EVDSYzJeDUm uvJJmbG7bAvqI9PPh9u..7dqVCuR_gyhGMTojy80Gs_n4rKf2uxOhs_xYmfs 8Ux_4zQ_FwLUyVEyPPrUsuXLwX9.mDjRGg46F4JoqFpK046KXKOom1Chtz6U H6vhVJENBNmLR0_PrMwrIOYGf1mIVCQMCciNoxqnh3MUwewIc04Ux3m3C1s3 YRro92k6I.3yAAhYUA8yIT9l8GT0EkSxifl119_OUB4AqB02R0BY- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [192.168.0.197] (d.sturek@67.124.201.128 with login) by smtp109.sbc.mail.mud.yahoo.com with SMTP; 23 Sep 2012 17:38:56 -0700 PDT User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Sun, 23 Sep 2012 17:36:25 -0700 From: Don Sturek To: , "Joel M. Halpern" Message-ID: Thread-Topic: [homenet] draft-ietf-homenet-arch-04 In-Reply-To: <201209232309.q8NN9FlR056677@gateway1.orleans.occnc.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: homenet@ietf.org Subject: Re: [homenet] draft-ietf-homenet-arch-04 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 00:39:02 -0000 Hi Curtis, SLAAC not working is a major problem. Don On 9/23/12 4:09 PM, "Curtis Villamizar" wrote: > >In message <505E83F6.3030900@joelhalpern.com> >"Joel M. Halpern" writes: > >> Since you invited flames... >> >> The argument on /64 as the longest prefix is not that it is magically >> unnatural. >> Rather, it is that there are a number of current and evolving protocols >> that depend upon that /64. The obvious example is that SLAAC does not >> work if subnets are longer than /64. >> >> The rules in this regard are written into approved RFCs. If homenet >> wants to change that, it really needs to go to 6man with a strong case. >> (for point-to-point inter-router links this was recently relaxed. >> >> At the same time, andy operator who insists on giving homes a /64 is >> being inappropriately restrictive. Homenet should say that, rather >>than >> trying to change the IPv6 architecture. >> >> Yours, >> Joel > >Joel, > >I don't consider your email a flame at all. Thanks for responding. > >SLAAC (which I am not at a fan of) won't work but DHCPv6 will so IMHO >no loss. CGA also won't work but then again I've also never been a >fan of security half measures. Yes anti-spoofing without prior >exchange of a key is nice, but no reasonable authorization could be >based on CGA without also exchanging some sort of key or cert and at >that point the CGA as a public key is redundant. > >If SLAAC and CGA are the only things that break *and* providers do >hand out prefixes that are too small, then /64 prefixes will have to >be subdivided. > >So a question for you is what else if anything will break? > >I also understand that you are suggesting that this be taken to 6man. >That is a good suggestion. > >Curtis > > >> On 9/22/2012 11:30 PM, Curtis Villamizar wrote: >> > 12. This is sure to be controversial. I pointed out that using >> > subnets longer than /64 is OK as long as they are not leaked >> > into global routing. Please read the text and changes before >> > exploding on this topic. It may be necessary to subnet a /64 >>if >> > that is all a provider will give you and you need subnets. It >> > does work and it is no more unnatural than subnetting a class-A >> > network would be in 1990. It means using DHCPv6 and not using >> > RA prefixes for GUA (otherwise SLAAC implementations would >> > likely try to use the whole bottom 64). >_______________________________________________ >homenet mailing list >homenet@ietf.org >https://www.ietf.org/mailman/listinfo/homenet From curtis@occnc.com Mon Sep 24 11:50: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 3BA2521F8894 for ; Mon, 24 Sep 2012 11:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.150, 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 iYEBf2XDFvVG for ; Mon, 24 Sep 2012 11:49:59 -0700 (PDT) Received: from gateway1.orleans.occnc.com (gateway1.orleans.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 63C5D21F884D for ; Mon, 24 Sep 2012 11:49:59 -0700 (PDT) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id q8OInuoN064065; Mon, 24 Sep 2012 14:49:56 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201209241849.q8OInuoN064065@gateway1.orleans.occnc.com> To: Don Sturek From: Curtis Villamizar In-reply-to: Your message of "Sun, 23 Sep 2012 17:36:25 PDT." Date: Mon, 24 Sep 2012 14:49:56 -0400 Cc: homenet@ietf.org, "Joel M. Halpern" , curtis@occnc.com Subject: Re: [homenet] draft-ietf-homenet-arch-04 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 18:50:00 -0000 In message Don Sturek writes: > Hi Curtis, > > SLAAC not working is a major problem. > > Don Don, Why? This is an assertion without basis as far as I am concerned. Except CGA there is nothing that breaks without SLAAC. Joel brought up ILNP in private email, but I beleive ILNP can also work as the constraints in ILNP are in the ILNP identifier which is not the same as the interface address in ILNP for which there is no constraint. I have subnets running fine using a few /112 allocated from within a /64 with fixed addresses on rack mount hosts and desktops and DHCPv6 for dynamic allocations for laptops. It works fine. Link local addresses are all that is needed to get DHCPv6 to work. No host ever receives a RA since my routers won't give them one, so no host ever tries to generate an address using SLAAC. The only constraint is that any host connecting to my Ethernet or wireless must run a DHCP client and if they want an IPv6 GUA must run a DHCPv6 client. DHCPv4 and DHCPv6 servers are available in every subnet except one GbE subnet in the rack and to a few hosts in my home office. So as far as I am concerned we have an assertion that no SLAAC is a problem and existance proof that it is not. Beside CGA and requiring that hosts run DHCPv6 if they want an IPv6 GUA, what can I not support on these /112 subnets? Curtis > On 9/23/12 4:09 PM, "Curtis Villamizar" wrote: > > > > >In message <505E83F6.3030900@joelhalpern.com> > >"Joel M. Halpern" writes: > > > >> Since you invited flames... > >> > >> The argument on /64 as the longest prefix is not that it is magically > >> unnatural. > >> Rather, it is that there are a number of current and evolving protocols > >> that depend upon that /64. The obvious example is that SLAAC does not > >> work if subnets are longer than /64. > >> > >> The rules in this regard are written into approved RFCs. If homenet > >> wants to change that, it really needs to go to 6man with a strong case. > >> (for point-to-point inter-router links this was recently relaxed. > >> > >> At the same time, andy operator who insists on giving homes a /64 is > >> being inappropriately restrictive. Homenet should say that, rather > >>than > >> trying to change the IPv6 architecture. > >> > >> Yours, > >> Joel > > > >Joel, > > > >I don't consider your email a flame at all. Thanks for responding. > > > >SLAAC (which I am not at a fan of) won't work but DHCPv6 will so IMHO > >no loss. CGA also won't work but then again I've also never been a > >fan of security half measures. Yes anti-spoofing without prior > >exchange of a key is nice, but no reasonable authorization could be > >based on CGA without also exchanging some sort of key or cert and at > >that point the CGA as a public key is redundant. > > > >If SLAAC and CGA are the only things that break *and* providers do > >hand out prefixes that are too small, then /64 prefixes will have to > >be subdivided. > > > >So a question for you is what else if anything will break? > > > >I also understand that you are suggesting that this be taken to 6man. > >That is a good suggestion. > > > >Curtis > > > > > >> On 9/22/2012 11:30 PM, Curtis Villamizar wrote: > >> > 12. This is sure to be controversial. I pointed out that using > >> > subnets longer than /64 is OK as long as they are not leaked > >> > into global routing. Please read the text and changes before > >> > exploding on this topic. It may be necessary to subnet a /64 > >>if > >> > that is all a provider will give you and you need subnets. It > >> > does work and it is no more unnatural than subnetting a class-A > >> > network would be in 1990. It means using DHCPv6 and not using > >> > RA prefixes for GUA (otherwise SLAAC implementations would > >> > likely try to use the whole bottom 64). > >_______________________________________________ > >homenet mailing list > >homenet@ietf.org > >https://www.ietf.org/mailman/listinfo/homenet From d.sturek@att.net Mon Sep 24 12:17: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 ED95521F8890 for ; Mon, 24 Sep 2012 12:17:15 -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 xYi8KLxpHHgv for ; Mon, 24 Sep 2012 12:17:15 -0700 (PDT) Received: from nm30-vm0.bullet.mail.sp2.yahoo.com (nm30-vm0.bullet.mail.sp2.yahoo.com [98.139.91.238]) by ietfa.amsl.com (Postfix) with SMTP id 4C4F821F888E for ; Mon, 24 Sep 2012 12:17:15 -0700 (PDT) Received: from [98.139.91.61] by nm30.bullet.mail.sp2.yahoo.com with NNFMP; 24 Sep 2012 19:17:08 -0000 Received: from [98.139.44.87] by tm1.bullet.mail.sp2.yahoo.com with NNFMP; 24 Sep 2012 19:17:08 -0000 Received: from [127.0.0.1] by omp1024.access.mail.sp2.yahoo.com with NNFMP; 24 Sep 2012 19:17:08 -0000 X-Yahoo-Newman-Id: 215365.50790.bm@omp1024.access.mail.sp2.yahoo.com Received: (qmail 92934 invoked from network); 24 Sep 2012 19:17:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1348514227; bh=9TT5Urwyw+XRkH5mjylPkxdtWnCBzxYwELXaMv/hlsg=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=Q6iG72fuDZ7NSCdZn80KUynh8xMaxWiDBikfMHP4DYqG0GKBFbZGi+cluCvwp8aevVuD+pJskI1y1ggrLL3y8HkZANVE7Uuc2OIxZii/12ERN6Iaa1RUVGZh+n+xK+CkRmthwygtgWTi8gPeuIHexnPXyaWGzsEm8DVFoUgpIlg= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: DnWMV2wVM1lf40hcIj6M8AXItGnMYNuZ7TDCw9JUymkKdec X3B4aIaYoKtBzYTYJMB7tE32rh33Rmm6yzGQ_4.BRsnp4_6m8olCQQKWNUNE q1ALvGfsk8zhmySanogwgmMZp7g9K_DURFhTa.0kKEmB_xhL2s4SGuxJT9Gd nxv_LT_wqO4QALQi4BMubKk0UxGL2WytpriTMSG3FDIgtpWtNZZz.XiPINC5 towVEWw.gXBtT4D28b_eaDadjBw.5TOaKSrhn.NfuIxRlnHcAhupIfX1Fg.V UVlSplRiMrZIkftCTe_F_qFE5bpUEXDLRp.5Gl9pAsRch2M_a6.RplB.IheQ Mx9Li78gUBN5guUsfNLe2mVQ4JDyBiRJEC2TMASivLlKVSAs9udwXjw65yS4 1MOJkEQUS1LXH7aY6iru4LVqrcmOc9jKLlfnUf9sIsi9xiCnetw8f3DrGFLe EqM92xLOJII7Zp306YVIW_3NkfmS4ARUq4ubZ2aIrrrrX8DlFiMdd4J3hvom M X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [10.1.1.105] (d.sturek@66.27.60.174 with login) by smtp103.sbc.mail.gq1.yahoo.com with SMTP; 24 Sep 2012 12:17:06 -0700 PDT User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Mon, 24 Sep 2012 12:17:03 -0700 From: Don Sturek To: Message-ID: Thread-Topic: [homenet] draft-ietf-homenet-arch-04 In-Reply-To: <201209241849.q8OInuoN064065@gateway1.orleans.occnc.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: homenet@ietf.org, "Joel M. Halpern" Subject: Re: [homenet] draft-ietf-homenet-arch-04 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 19:17:16 -0000 Hi Curtis, Here is the use case: 1) Customer has a legacy AP in their house 2) Customer brings home new devices supporting IPv6 (which are designed to communicate only with other IPv6 based devices in the home) 3) The only way these new devices can communicate is through address assignment using SLAAC and then some discovery method the two new devices support (without support from the AP). Here these devices are assuming bridging through the AP...... Placing a requirement that every customer who buys a new IPv6 device, intended to communicate only with other IPv6 devices in the home, will require a forklift upgrade of a deployed network in order to work will not be popular. Don On 9/24/12 11:49 AM, "Curtis Villamizar" wrote: > >In message >Don Sturek writes: > >> Hi Curtis, >> >> SLAAC not working is a major problem. >> >> Don > > >Don, > >Why? This is an assertion without basis as far as I am concerned. >Except CGA there is nothing that breaks without SLAAC. Joel brought >up ILNP in private email, but I beleive ILNP can also work as the >constraints in ILNP are in the ILNP identifier which is not the same >as the interface address in ILNP for which there is no constraint. > >I have subnets running fine using a few /112 allocated from within a >/64 with fixed addresses on rack mount hosts and desktops and DHCPv6 >for dynamic allocations for laptops. It works fine. Link local >addresses are all that is needed to get DHCPv6 to work. No host ever >receives a RA since my routers won't give them one, so no host ever >tries to generate an address using SLAAC. The only constraint is that >any host connecting to my Ethernet or wireless must run a DHCP client >and if they want an IPv6 GUA must run a DHCPv6 client. DHCPv4 and >DHCPv6 servers are available in every subnet except one GbE subnet in >the rack and to a few hosts in my home office. > >So as far as I am concerned we have an assertion that no SLAAC is a >problem and existance proof that it is not. Beside CGA and requiring >that hosts run DHCPv6 if they want an IPv6 GUA, what can I not support >on these /112 subnets? > >Curtis > > >> On 9/23/12 4:09 PM, "Curtis Villamizar" wrote: >> >> > >> >In message <505E83F6.3030900@joelhalpern.com> >> >"Joel M. Halpern" writes: >> > >> >> Since you invited flames... >> >> >> >> The argument on /64 as the longest prefix is not that it is magically >> >> unnatural. >> >> Rather, it is that there are a number of current and evolving >>protocols >> >> that depend upon that /64. The obvious example is that SLAAC does >>not >> >> work if subnets are longer than /64. >> >> >> >> The rules in this regard are written into approved RFCs. If homenet >> >> wants to change that, it really needs to go to 6man with a strong >>case. >> >> (for point-to-point inter-router links this was recently relaxed. >> >> >> >> At the same time, andy operator who insists on giving homes a /64 is >> >> being inappropriately restrictive. Homenet should say that, rather >> >>than >> >> trying to change the IPv6 architecture. >> >> >> >> Yours, >> >> Joel >> > >> >Joel, >> > >> >I don't consider your email a flame at all. Thanks for responding. >> > >> >SLAAC (which I am not at a fan of) won't work but DHCPv6 will so IMHO >> >no loss. CGA also won't work but then again I've also never been a >> >fan of security half measures. Yes anti-spoofing without prior >> >exchange of a key is nice, but no reasonable authorization could be >> >based on CGA without also exchanging some sort of key or cert and at >> >that point the CGA as a public key is redundant. >> > >> >If SLAAC and CGA are the only things that break *and* providers do >> >hand out prefixes that are too small, then /64 prefixes will have to >> >be subdivided. >> > >> >So a question for you is what else if anything will break? >> > >> >I also understand that you are suggesting that this be taken to 6man. >> >That is a good suggestion. >> > >> >Curtis >> > >> > >> >> On 9/22/2012 11:30 PM, Curtis Villamizar wrote: >> >> > 12. This is sure to be controversial. I pointed out that using >> >> > subnets longer than /64 is OK as long as they are not leaked >> >> > into global routing. Please read the text and changes >>before >> >> > exploding on this topic. It may be necessary to subnet a >>/64 >> >>if >> >> > that is all a provider will give you and you need subnets. >>It >> >> > does work and it is no more unnatural than subnetting a >>class-A >> >> > network would be in 1990. It means using DHCPv6 and not >>using >> >> > RA prefixes for GUA (otherwise SLAAC implementations would >> >> > likely try to use the whole bottom 64). >> >_______________________________________________ >> >homenet mailing list >> >homenet@ietf.org >> >https://www.ietf.org/mailman/listinfo/homenet > >_______________________________________________ >homenet mailing list >homenet@ietf.org >https://www.ietf.org/mailman/listinfo/homenet From gettysjim@gmail.com Mon Sep 24 13:08: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 B1B1521F886B for ; Mon, 24 Sep 2012 13:08:42 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id csm2IV34Vj5Z for ; Mon, 24 Sep 2012 13:08:41 -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 A882421F8867 for ; Mon, 24 Sep 2012 13:08:41 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so7330731vcb.31 for ; Mon, 24 Sep 2012 13:08:41 -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=6F0VVTqB0pJwuVFQbW3GviX8YJw00LM82niBeP9MkwM=; b=lKrw3ETXyA+Bvm3s3Fz+SZip8FqsWoBc24jGGo8U87w6FLodPgdyY8U/EVKvKNPDrW +gLlV0iIuq2yMZOOtHIksKTTSXwPyXHHzCsH/7ay9BuDS07OeGprMT6jFeAprMBtr9Ba JhjSynOag+p9JbQIl0pNhXHDJ/7BgvEWjEMasz3J+iffMZNkLrv9vWnMWwwPdBlDBJQ/ V9WK/sH/+bCAwoon96O7unbrFRZgr9GMy6jVYX8JMphZSVsj4spCaRxntADp5oa5xYjG dftk/sZgDkhiNLUpbaBeADwERlvdPEoQX7UTQSL2+y6E5LtP/z7DSQNE5LWOfqDr7W8l uucw== Received: by 10.52.33.165 with SMTP id s5mr6335074vdi.51.1348517320928; Mon, 24 Sep 2012 13:08:40 -0700 (PDT) Received: from [192.168.1.80] (c-24-218-177-150.hsd1.ma.comcast.net. [24.218.177.150]) by mx.google.com with ESMTPS id l15sm834566vdt.14.2012.09.24.13.08.40 (version=SSLv3 cipher=OTHER); Mon, 24 Sep 2012 13:08:40 -0700 (PDT) Sender: Jim Gettys Message-ID: <5060BDC7.6020403@freedesktop.org> Date: Mon, 24 Sep 2012 16:08:39 -0400 From: Jim Gettys Organization: Bell Labs User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Don Sturek References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org, "Joel M. Halpern" , curtis@occnc.com Subject: Re: [homenet] draft-ietf-homenet-arch-04 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 20:08:42 -0000 On 09/24/2012 03:17 PM, Don Sturek wrote: > Hi Curtis, > > Here is the use case: > 1) Customer has a legacy AP in their house > 2) Customer brings home new devices supporting IPv6 (which are designed > to communicate only with other IPv6 based devices in the home) > 3) The only way these new devices can communicate is through address > assignment using SLAAC and then some discovery method the two new devices > support (without support from the AP). Here these devices are assuming > bridging through the AP...... And since current legacy AP's all bridge, we win (even though we need to route in the future). > > Placing a requirement that every customer who buys a new IPv6 device, > intended to communicate only with other IPv6 devices in the home, will > require a forklift upgrade of a deployed network in order to work will not > be popular. Good point. I loathe DHCP (of any sort) *for basic address assignment, anyway* in the home environment. The loathing comes from the exquisite pain of suffering with a flaky home network for several months, before realising I had a rogue DHCP server somewhere on my network (from wireshark). I then had to take the mac address, figure out who may have manufactured some device from that information, and finally figured out the little VOIP ATA adaptor I had been given liked to do DHCP. This was by far the hardest debugging I've had to do in my home network in normal operation. This is well beyond normal home debugging capability of consumers. - Jim - Jim > > Don > > > > > On 9/24/12 11:49 AM, "Curtis Villamizar" wrote: > >> In message >> Don Sturek writes: >> >>> Hi Curtis, >>> >>> SLAAC not working is a major problem. >>> >>> Don >> >> Don, >> >> Why? This is an assertion without basis as far as I am concerned. >> Except CGA there is nothing that breaks without SLAAC. Joel brought >> up ILNP in private email, but I beleive ILNP can also work as the >> constraints in ILNP are in the ILNP identifier which is not the same >> as the interface address in ILNP for which there is no constraint. >> >> I have subnets running fine using a few /112 allocated from within a >> /64 with fixed addresses on rack mount hosts and desktops and DHCPv6 >> for dynamic allocations for laptops. It works fine. Link local >> addresses are all that is needed to get DHCPv6 to work. No host ever >> receives a RA since my routers won't give them one, so no host ever >> tries to generate an address using SLAAC. The only constraint is that >> any host connecting to my Ethernet or wireless must run a DHCP client >> and if they want an IPv6 GUA must run a DHCPv6 client. DHCPv4 and >> DHCPv6 servers are available in every subnet except one GbE subnet in >> the rack and to a few hosts in my home office. >> >> So as far as I am concerned we have an assertion that no SLAAC is a >> problem and existance proof that it is not. Beside CGA and requiring >> that hosts run DHCPv6 if they want an IPv6 GUA, what can I not support >> on these /112 subnets? >> >> Curtis >> >> >>> On 9/23/12 4:09 PM, "Curtis Villamizar" wrote: >>> >>>> In message <505E83F6.3030900@joelhalpern.com> >>>> "Joel M. Halpern" writes: >>>> >>>>> Since you invited flames... >>>>> >>>>> The argument on /64 as the longest prefix is not that it is magically >>>>> unnatural. >>>>> Rather, it is that there are a number of current and evolving >>> protocols >>>>> that depend upon that /64. The obvious example is that SLAAC does >>> not >>>>> work if subnets are longer than /64. >>>>> >>>>> The rules in this regard are written into approved RFCs. If homenet >>>>> wants to change that, it really needs to go to 6man with a strong >>> case. >>>>> (for point-to-point inter-router links this was recently relaxed. >>>>> >>>>> At the same time, andy operator who insists on giving homes a /64 is >>>>> being inappropriately restrictive. Homenet should say that, rather >>>>> than >>>>> trying to change the IPv6 architecture. >>>>> >>>>> Yours, >>>>> Joel >>>> Joel, >>>> >>>> I don't consider your email a flame at all. Thanks for responding. >>>> >>>> SLAAC (which I am not at a fan of) won't work but DHCPv6 will so IMHO >>>> no loss. CGA also won't work but then again I've also never been a >>>> fan of security half measures. Yes anti-spoofing without prior >>>> exchange of a key is nice, but no reasonable authorization could be >>>> based on CGA without also exchanging some sort of key or cert and at >>>> that point the CGA as a public key is redundant. >>>> >>>> If SLAAC and CGA are the only things that break *and* providers do >>>> hand out prefixes that are too small, then /64 prefixes will have to >>>> be subdivided. >>>> >>>> So a question for you is what else if anything will break? >>>> >>>> I also understand that you are suggesting that this be taken to 6man. >>>> That is a good suggestion. >>>> >>>> Curtis >>>> >>>> >>>>> On 9/22/2012 11:30 PM, Curtis Villamizar wrote: >>>>>> 12. This is sure to be controversial. I pointed out that using >>>>>> subnets longer than /64 is OK as long as they are not leaked >>>>>> into global routing. Please read the text and changes >>> before >>>>>> exploding on this topic. It may be necessary to subnet a >>> /64 >>>>> if >>>>>> that is all a provider will give you and you need subnets. >>> It >>>>>> does work and it is no more unnatural than subnetting a >>> class-A >>>>>> network would be in 1990. It means using DHCPv6 and not >>> using >>>>>> RA prefixes for GUA (otherwise SLAAC implementations would >>>>>> likely try to use the whole bottom 64). >>>> _______________________________________________ >>>> homenet mailing list >>>> homenet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/homenet >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From curtis@occnc.com Mon Sep 24 15:24: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 9F62F1F0C73 for ; Mon, 24 Sep 2012 15:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.46 X-Spam-Level: X-Spam-Status: No, score=-2.46 tagged_above=-999 required=5 tests=[AWL=0.140, 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 HvYfwbyQkrsN for ; Mon, 24 Sep 2012 15:24:23 -0700 (PDT) Received: from gateway1.orleans.occnc.com (gateway1.orleans.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 875541F041D for ; Mon, 24 Sep 2012 15:24:23 -0700 (PDT) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id q8OMOA8D065304; Mon, 24 Sep 2012 18:24:10 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201209242224.q8OMOA8D065304@gateway1.orleans.occnc.com> To: Don Sturek From: Curtis Villamizar In-reply-to: Your message of "Mon, 24 Sep 2012 12:17:03 PDT." Date: Mon, 24 Sep 2012 18:24:10 -0400 Cc: homenet@ietf.org, "Joel M. Halpern" , curtis@occnc.com Subject: Re: [homenet] draft-ietf-homenet-arch-04 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 22:24:24 -0000 In message Don Sturek writes: > Hi Curtis, > > Here is the use case: > 1) Customer has a legacy AP in their house > 2) Customer brings home new devices supporting IPv6 (which are designed > to communicate only with other IPv6 based devices in the home) > 3) The only way these new devices can communicate is through address > assignment using SLAAC and then some discovery method the two new devices > support (without support from the AP). Here these devices are assuming > bridging through the AP...... Fine. Use link local addresses. SLAAC simply can't be used with the GUA prefix. SLAAC can be used with link local or ULA. Does this mean problem solved? > Placing a requirement that every customer who buys a new IPv6 device, > intended to communicate only with other IPv6 devices in the home, will > require a forklift upgrade of a deployed network in order to work will not > be popular. > > Don Maybe I wasn't clear in the summary paragraph. SLAAC can still be used but not for GUA. For the GUA DHCPv6 can be used and SLACC has to be avoided *if* the provider forced subdividing a /64 by refusing to allocate a prefix large enough (for example a fixed policy of /64 only for homes). I am not suggesting depricating SLAAC or not implementing it. All I am suggesting is that *if* you have a prefix that is too small, then you can sacrifice CGA but still support all the subnets you need by not providing an RA and providing DHCPv6 for the GUA prefixes that need to be longer than /64 within the homenet. If providers are all cooperative and are all willing to give out short enough prefixes, then the "if" in the prior paragraph never evaluates to "true" and the suggestion is a NOOP. I hope that was a bit more clear. btw- It seems to me that some respondents are reading the diffs to the draft and are replying only to the summary (or worse yet replying only to Joel's comment on summary point #12). Any reply is better than none, but please also read the diffs to the draft. Curtis > On 9/24/12 11:49 AM, "Curtis Villamizar" wrote: > > > > >In message > >Don Sturek writes: > > > >> Hi Curtis, > >> > >> SLAAC not working is a major problem. > >> > >> Don > > > > > >Don, > > > >Why? This is an assertion without basis as far as I am concerned. > >Except CGA there is nothing that breaks without SLAAC. Joel brought > >up ILNP in private email, but I beleive ILNP can also work as the > >constraints in ILNP are in the ILNP identifier which is not the same > >as the interface address in ILNP for which there is no constraint. > > > >I have subnets running fine using a few /112 allocated from within a > >/64 with fixed addresses on rack mount hosts and desktops and DHCPv6 > >for dynamic allocations for laptops. It works fine. Link local > >addresses are all that is needed to get DHCPv6 to work. No host ever > >receives a RA since my routers won't give them one, so no host ever > >tries to generate an address using SLAAC. The only constraint is that > >any host connecting to my Ethernet or wireless must run a DHCP client > >and if they want an IPv6 GUA must run a DHCPv6 client. DHCPv4 and > >DHCPv6 servers are available in every subnet except one GbE subnet in > >the rack and to a few hosts in my home office. > > > >So as far as I am concerned we have an assertion that no SLAAC is a > >problem and existance proof that it is not. Beside CGA and requiring > >that hosts run DHCPv6 if they want an IPv6 GUA, what can I not support > >on these /112 subnets? > > > >Curtis > > > > > >> On 9/23/12 4:09 PM, "Curtis Villamizar" wrote: > >> > >> > > >> >In message <505E83F6.3030900@joelhalpern.com> > >> >"Joel M. Halpern" writes: > >> > > >> >> Since you invited flames... > >> >> > >> >> The argument on /64 as the longest prefix is not that it is magically > >> >> unnatural. > >> >> Rather, it is that there are a number of current and evolving > >>protocols > >> >> that depend upon that /64. The obvious example is that SLAAC does > >>not > >> >> work if subnets are longer than /64. > >> >> > >> >> The rules in this regard are written into approved RFCs. If homenet > >> >> wants to change that, it really needs to go to 6man with a strong > >>case. > >> >> (for point-to-point inter-router links this was recently relaxed. > >> >> > >> >> At the same time, andy operator who insists on giving homes a /64 is > >> >> being inappropriately restrictive. Homenet should say that, rather > >> >>than > >> >> trying to change the IPv6 architecture. > >> >> > >> >> Yours, > >> >> Joel > >> > > >> >Joel, > >> > > >> >I don't consider your email a flame at all. Thanks for responding. > >> > > >> >SLAAC (which I am not at a fan of) won't work but DHCPv6 will so IMHO > >> >no loss. CGA also won't work but then again I've also never been a > >> >fan of security half measures. Yes anti-spoofing without prior > >> >exchange of a key is nice, but no reasonable authorization could be > >> >based on CGA without also exchanging some sort of key or cert and at > >> >that point the CGA as a public key is redundant. > >> > > >> >If SLAAC and CGA are the only things that break *and* providers do > >> >hand out prefixes that are too small, then /64 prefixes will have to > >> >be subdivided. > >> > > >> >So a question for you is what else if anything will break? > >> > > >> >I also understand that you are suggesting that this be taken to 6man. > >> >That is a good suggestion. > >> > > >> >Curtis > >> > > >> > > >> >> On 9/22/2012 11:30 PM, Curtis Villamizar wrote: > >> >> > 12. This is sure to be controversial. I pointed out that using > >> >> > subnets longer than /64 is OK as long as they are not leaked > >> >> > into global routing. Please read the text and changes > >>before > >> >> > exploding on this topic. It may be necessary to subnet a > >>/64 > >> >>if > >> >> > that is all a provider will give you and you need subnets. > >>It > >> >> > does work and it is no more unnatural than subnetting a > >>class-A > >> >> > network would be in 1990. It means using DHCPv6 and not > >>using > >> >> > RA prefixes for GUA (otherwise SLAAC implementations would > >> >> > likely try to use the whole bottom 64). > >> >_______________________________________________ > >> >homenet mailing list > >> >homenet@ietf.org > >> >https://www.ietf.org/mailman/listinfo/homenet > > > >_______________________________________________ > >homenet mailing list > >homenet@ietf.org > >https://www.ietf.org/mailman/listinfo/homenet From mellon@fugue.com Mon Sep 24 15:36:20 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EACA1F0C98 for ; Mon, 24 Sep 2012 15:36:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b3XwBp4k8StT for ; Mon, 24 Sep 2012 15:36:18 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id EBDA21F041D for ; Mon, 24 Sep 2012 15:36:17 -0700 (PDT) Received: from [10.0.1.24] (unknown [64.215.212.51]) by toccata.fugue.com (Postfix) with ESMTPSA id CAD9F238088A; Mon, 24 Sep 2012 18:36:15 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Ted Lemon In-Reply-To: <5060BDC7.6020403@freedesktop.org> Date: Mon, 24 Sep 2012 18:36:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <23EF7D6F-F3E0-40D6-9ABA-8EF56CFCE773@fugue.com> References: <5060BDC7.6020403@freedesktop.org> To: Jim Gettys X-Mailer: Apple Mail (2.1498) Cc: homenet@ietf.org, "Joel M. Halpern" , Don Sturek , curtis@occnc.com Subject: Re: [homenet] draft-ietf-homenet-arch-04 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 22:36:20 -0000 On Sep 24, 2012, at 4:08 PM, Jim Gettys wrote: > This was by far the hardest debugging I've had to do in my home = network > in normal operation. In all fairness, the exact same kind of brokenness can happen with rogue = RA messages, and a non-geek will have an equally hard time diagnosing = it. From mike@mtcc.com Mon Sep 24 15:53: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 4E8141F0C59 for ; Mon, 24 Sep 2012 15:53:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 5BxgvKwwtwtv for ; Mon, 24 Sep 2012 15:53: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 AD33D1F042B for ; Mon, 24 Sep 2012 15:53: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 q8OMqt0S018776 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 24 Sep 2012 15:52:56 -0700 Message-ID: <5060E447.2030500@mtcc.com> Date: Mon, 24 Sep 2012 15:52:55 -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: <5060BDC7.6020403@freedesktop.org> <23EF7D6F-F3E0-40D6-9ABA-8EF56CFCE773@fugue.com> In-Reply-To: <23EF7D6F-F3E0-40D6-9ABA-8EF56CFCE773@fugue.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=663; t=1348527177; x=1349391177; 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]=20draft-ietf-homenet-arch-04 |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=Qy5pbwGTF00Dvw+IhmD9OpTq4inSDbxHemDvNRb/A/A=; b=frcShF5qJ4XinM/peQLazTPKH/CpAYX1MV7x9UygCP0NgCoWcxLeOLJ7rL OlvZyfjkGaE28BS1Cv/Gy2z6oxErX3aErR80EXcmOXv9obtH03Y1n26KUlql SnU0t6INiEBXVaXV+/fKZudag9Xgug32vWXX0kGNWJ1Ycssw6XTIY=; 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, "Joel M. Halpern" , Don Sturek , Jim Gettys , curtis@occnc.com Subject: Re: [homenet] draft-ietf-homenet-arch-04 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 22:53:02 -0000 On 09/24/2012 03:36 PM, Ted Lemon wrote: > On Sep 24, 2012, at 4:08 PM, Jim Gettys wrote: >> This was by far the hardest debugging I've had to do in my home network >> in normal operation. > In all fairness, the exact same kind of brokenness can happen with rogue RA messages, and a non-geek will have an equally hard time diagnosing it. > I'm trying to think of whether it's worse with v6: with v6 it at least shows every address that it's auto-configured rather than the luck of the draw for dhcp of whether you at any renew time happen to get the rogue server. Not that normal human beings have ever typed "ifconfig". Mike From mellon@fugue.com Mon Sep 24 16:23: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 0D44221F8551 for ; Mon, 24 Sep 2012 16:23:11 -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 8hX8As+xDxeK for ; Mon, 24 Sep 2012 16:23:10 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id A6C4421F854E for ; Mon, 24 Sep 2012 16:23:10 -0700 (PDT) Received: from [10.0.1.24] (unknown [64.215.212.51]) by toccata.fugue.com (Postfix) with ESMTPSA id C24D9238088A; Mon, 24 Sep 2012 19:23:07 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Ted Lemon In-Reply-To: <5060E447.2030500@mtcc.com> Date: Mon, 24 Sep 2012 19:23:05 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0A674251-0063-4228-89C1-7BFA35A84BD8@fugue.com> References: <5060BDC7.6020403@freedesktop.org> <23EF7D6F-F3E0-40D6-9ABA-8EF56CFCE773@fugue.com> <5060E447.2030500@mtcc.com> To: Michael Thomas X-Mailer: Apple Mail (2.1498) Cc: homenet@ietf.org, "Joel M. Halpern" , Don Sturek , Jim Gettys , curtis@occnc.com Subject: Re: [homenet] draft-ietf-homenet-arch-04 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 23:23:11 -0000 On Sep 24, 2012, at 6:52 PM, Michael Thomas wrote: > I'm trying to think of whether it's worse with v6: with v6 it at least > shows every address that it's auto-configured rather than the luck > of the draw for dhcp of whether you at any renew time happen to > get the rogue server. Not that normal human beings have ever typed > "ifconfig". If you have a good happy eyeballs implementation, an IPv6 host ought to = be able to ride right over it, as long as the rogue router isn't doing = an MiTM attack.= From gettysjim@gmail.com Mon Sep 24 16:37: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 96ADF1F0C3A for ; Mon, 24 Sep 2012 16:37:52 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YuH3RcanPPGF for ; Mon, 24 Sep 2012 16:37:52 -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 0B6891F042B for ; Mon, 24 Sep 2012 16:37:51 -0700 (PDT) Received: by ggm4 with SMTP id 4so29189ggm.31 for ; Mon, 24 Sep 2012 16:37:51 -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=kKwyH3eb08viZE6JBwZvOuli9z84dNxGbVhmieiJqjA=; b=l4CN+aiew3VxgpHXrEJhaxJTz1EQDhZWtNU81sghQ6m2/EnyAX+RYfp5nlX7qvPiUB ZxE3AXfN9IjpiUW86muIa+3FQPPUOLkJveM036i6gCem79R1f7SfBH/YqrST1l4YvYJh jqeQxAvq/bvNOZauObDr5L/Vxv0DtqPy4oyt1lN6oOkxf/CjZWsAtIFw5HpgUA2m0tt1 PoEYC6cAQ4HeTQJ2Vu5KdllOuhxaetqfejAlFe6p8e5AHFEbTnoPoDD2hXdlb0hBAdOb W5AO64NnH24qdl7426xiiu6FMpxHh2v3VY4ptQBuRqkhlY2MLcyB7fk89zMe14jthUfm deIw== Received: by 10.236.127.199 with SMTP id d47mr14403753yhi.11.1348529871619; Mon, 24 Sep 2012 16:37:51 -0700 (PDT) Received: from [192.168.1.80] (c-24-218-177-150.hsd1.ma.comcast.net. [24.218.177.150]) by mx.google.com with ESMTPS id f15sm18022203anm.9.2012.09.24.16.37.50 (version=SSLv3 cipher=OTHER); Mon, 24 Sep 2012 16:37:51 -0700 (PDT) Sender: Jim Gettys Message-ID: <5060EEBF.5060308@freedesktop.org> Date: Mon, 24 Sep 2012 19:37:35 -0400 From: Jim Gettys Organization: Bell Labs User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Ted Lemon References: <5060BDC7.6020403@freedesktop.org> <23EF7D6F-F3E0-40D6-9ABA-8EF56CFCE773@fugue.com> In-Reply-To: <23EF7D6F-F3E0-40D6-9ABA-8EF56CFCE773@fugue.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org, "Joel M. Halpern" , Don Sturek , curtis@occnc.com Subject: Re: [homenet] draft-ietf-homenet-arch-04 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 23:37:52 -0000 On 09/24/2012 06:36 PM, Ted Lemon wrote: > On Sep 24, 2012, at 4:08 PM, Jim Gettys wrote: >> This was by far the hardest debugging I've had to do in my home network >> in normal operation. > In all fairness, the exact same kind of brokenness can happen with rogue RA messages, and a non-geek will have an equally hard time diagnosing it. The worst of this was that the little box was much slower than my regular dhcp server, so it was like a 20% failure rate. Sigh. Be that as it may, relying on dhcp to get addresses strikes me as much more error prone. - Jim > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From curtis@occnc.com Mon Sep 24 17:11: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 5567A21F8860 for ; Mon, 24 Sep 2012 17:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=0.132, 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 P4qU3royXZ7S for ; Mon, 24 Sep 2012 17:11:05 -0700 (PDT) Received: from gateway1.orleans.occnc.com (gateway1.orleans.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 50FC121F885D for ; Mon, 24 Sep 2012 17:11:05 -0700 (PDT) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id q8P0B12L065909; Mon, 24 Sep 2012 20:11:01 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201209250011.q8P0B12L065909@gateway1.orleans.occnc.com> To: Jim Gettys From: Curtis Villamizar In-reply-to: Your message of "Mon, 24 Sep 2012 16:08:39 EDT." <5060BDC7.6020403@freedesktop.org> Date: Mon, 24 Sep 2012 20:11:01 -0400 Cc: homenet@ietf.org, "Joel M. Halpern" , Don Sturek , curtis@occnc.com Subject: Re: [homenet] draft-ietf-homenet-arch-04 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, 25 Sep 2012 00:11:06 -0000 In message <5060BDC7.6020403@freedesktop.org> Jim Gettys writes: > On 09/24/2012 03:17 PM, Don Sturek wrote: > > Hi Curtis, > > > > Here is the use case: > > 1) Customer has a legacy AP in their house > > 2) Customer brings home new devices supporting IPv6 (which are designed > > to communicate only with other IPv6 based devices in the home) > > 3) The only way these new devices can communicate is through address > > assignment using SLAAC and then some discovery method the two new devices > > support (without support from the AP). Here these devices are assuming > > bridging through the AP...... > > And since current legacy AP's all bridge, we win (even though we need to > route in the future). Jim, The point was how do you get local IPv6 within the home with the legacy AP that does only IPv4 and just does bridging of IPv6. First of all you have no subnets. There is no CER to do DHCPv6. In this case you use link local or if everything has a MAC you can use ULA based on the MAC addressses. > > Placing a requirement that every customer who buys a new IPv6 device, > > intended to communicate only with other IPv6 devices in the home, will > > require a forklift upgrade of a deployed network in order to work will not > > be popular. > > Good point. But invalid. The use case Don gave would still work fine. Only GUA addresses are affected. > I loathe DHCP (of any sort) *for basic address assignment, anyway* in > the home environment. > > The loathing comes from the exquisite pain of suffering with a flaky > home network for several months, before realising I had a rogue DHCP > server somewhere on my network (from wireshark). I then had to take the > mac address, figure out who may have manufactured some device from that > information, and finally figured out the little VOIP ATA adaptor I had > been given liked to do DHCP. It did DHCP on the *WAN side*? You didn't put the rest of your network behind the VOIP box on the LAN side I hope. > This was by far the hardest debugging I've had to do in my home network > in normal operation. > > This is well beyond normal home debugging capability of consumers. > - Jim We all have plenty of crappy IPv4 product horror stories. My VOIP phone locked up now and then and I figured out that if the call lasted longer than the DHCPv4 lease, then it lost the least because it didn't try to renew it. Not only did the call drop, but the device locked up. The first solution was to reboot it now and then. The answer was to configure a fixed address. I was lucky to figure it out before my wife threw the phone through a window. For all I know a later firmware upgrade might have fixed it. VOIP might be more popular if VOIP phones under $600 worked reasonably well. Both nice stories, but both are DHCPv4 related and have nothing at all to do with SLAAC. Curtis > > Don > > > > > > > > > > On 9/24/12 11:49 AM, "Curtis Villamizar" wrote: > > > >> In message > >> Don Sturek writes: > >> > >>> Hi Curtis, > >>> > >>> SLAAC not working is a major problem. > >>> > >>> Don > >> > >> Don, > >> > >> Why? This is an assertion without basis as far as I am concerned. > >> Except CGA there is nothing that breaks without SLAAC. Joel brought > >> up ILNP in private email, but I beleive ILNP can also work as the > >> constraints in ILNP are in the ILNP identifier which is not the same > >> as the interface address in ILNP for which there is no constraint. > >> > >> I have subnets running fine using a few /112 allocated from within a > >> /64 with fixed addresses on rack mount hosts and desktops and DHCPv6 > >> for dynamic allocations for laptops. It works fine. Link local > >> addresses are all that is needed to get DHCPv6 to work. No host ever > >> receives a RA since my routers won't give them one, so no host ever > >> tries to generate an address using SLAAC. The only constraint is that > >> any host connecting to my Ethernet or wireless must run a DHCP client > >> and if they want an IPv6 GUA must run a DHCPv6 client. DHCPv4 and > >> DHCPv6 servers are available in every subnet except one GbE subnet in > >> the rack and to a few hosts in my home office. > >> > >> So as far as I am concerned we have an assertion that no SLAAC is a > >> problem and existance proof that it is not. Beside CGA and requiring > >> that hosts run DHCPv6 if they want an IPv6 GUA, what can I not support > >> on these /112 subnets? > >> > >> Curtis > >> > >> > >>> On 9/23/12 4:09 PM, "Curtis Villamizar" wrote: > >>> > >>>> In message <505E83F6.3030900@joelhalpern.com> > >>>> "Joel M. Halpern" writes: > >>>> > >>>>> Since you invited flames... > >>>>> > >>>>> The argument on /64 as the longest prefix is not that it is magically > >>>>> unnatural. > >>>>> Rather, it is that there are a number of current and evolving > >>> protocols > >>>>> that depend upon that /64. The obvious example is that SLAAC does > >>> not > >>>>> work if subnets are longer than /64. > >>>>> > >>>>> The rules in this regard are written into approved RFCs. If homenet > >>>>> wants to change that, it really needs to go to 6man with a strong > >>> case. > >>>>> (for point-to-point inter-router links this was recently relaxed. > >>>>> > >>>>> At the same time, andy operator who insists on giving homes a /64 is > >>>>> being inappropriately restrictive. Homenet should say that, rather > >>>>> than > >>>>> trying to change the IPv6 architecture. > >>>>> > >>>>> Yours, > >>>>> Joel > >>>> Joel, > >>>> > >>>> I don't consider your email a flame at all. Thanks for responding. > >>>> > >>>> SLAAC (which I am not at a fan of) won't work but DHCPv6 will so IMHO > >>>> no loss. CGA also won't work but then again I've also never been a > >>>> fan of security half measures. Yes anti-spoofing without prior > >>>> exchange of a key is nice, but no reasonable authorization could be > >>>> based on CGA without also exchanging some sort of key or cert and at > >>>> that point the CGA as a public key is redundant. > >>>> > >>>> If SLAAC and CGA are the only things that break *and* providers do > >>>> hand out prefixes that are too small, then /64 prefixes will have to > >>>> be subdivided. > >>>> > >>>> So a question for you is what else if anything will break? > >>>> > >>>> I also understand that you are suggesting that this be taken to 6man. > >>>> That is a good suggestion. > >>>> > >>>> Curtis > >>>> > >>>> > >>>>> On 9/22/2012 11:30 PM, Curtis Villamizar wrote: > >>>>>> 12. This is sure to be controversial. I pointed out that using > >>>>>> subnets longer than /64 is OK as long as they are not leaked > >>>>>> into global routing. Please read the text and changes > >>> before > >>>>>> exploding on this topic. It may be necessary to subnet a > >>> /64 > >>>>> if > >>>>>> that is all a provider will give you and you need subnets. > >>> It > >>>>>> does work and it is no more unnatural than subnetting a > >>> class-A > >>>>>> network would be in 1990. It means using DHCPv6 and not > >>> using > >>>>>> RA prefixes for GUA (otherwise SLAAC implementations would > >>>>>> likely try to use the whole bottom 64). From gettysjim@gmail.com Mon Sep 24 17:17: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 7BA831F041D for ; Mon, 24 Sep 2012 17:17:01 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H4bGzOTi2VCQ for ; Mon, 24 Sep 2012 17:17:00 -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 5ECC421E8054 for ; Mon, 24 Sep 2012 17:17:00 -0700 (PDT) Received: by yenl13 with SMTP id l13so1903831yen.31 for ; Mon, 24 Sep 2012 17:17:00 -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=JTjdfM80ACtV5+W1AYTXXnt6WITdQMv0q+u7KNAH0MM=; b=Jx9SytWmFRM4WH0o0hVSvApuXaou645N4iRoxUpvtx7dLMsjj6mKBl7j9MgCK4c6ZM Fwx6m6Y5pc/rZ1Rw8JrkuQbCEJC6R+TNRDNqa4Amu7UWBsg4DG9PL8x4PBIBDLwZlPiH olpRi4B5OfP4vp6byFTVRMgPZJ/JoBIr2cHJYbfeVu0s2qPRJ0/6bmwbPAW181S7jAdE pVIHVdIxzYEWBDqx6WqUvcVshK8QzzsHjGv6GouSULFv3SthMHuPcA67aJV0hRxsaDRj Ca9+eEOoXI8cbLvDLjY2BEzZrgXesANGxQSgKJCv2eDqEX5Q290j9oNsntEY5ItR9f4V YiEw== Received: by 10.236.42.69 with SMTP id i45mr14390135yhb.7.1348532219994; Mon, 24 Sep 2012 17:16:59 -0700 (PDT) Received: from [192.168.1.80] (c-24-218-177-150.hsd1.ma.comcast.net. [24.218.177.150]) by mx.google.com with ESMTPS id a6sm14874849anm.22.2012.09.24.17.16.56 (version=SSLv3 cipher=OTHER); Mon, 24 Sep 2012 17:16:59 -0700 (PDT) Sender: Jim Gettys Message-ID: <5060F7F7.9040103@freedesktop.org> Date: Mon, 24 Sep 2012 20:16:55 -0400 From: Jim Gettys Organization: Bell Labs User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: curtis@occnc.com References: <201209250011.q8P0B12L065909@gateway1.orleans.occnc.com> In-Reply-To: <201209250011.q8P0B12L065909@gateway1.orleans.occnc.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org, "Joel M. Halpern" , Don Sturek Subject: Re: [homenet] draft-ietf-homenet-arch-04 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 00:17:01 -0000 On 09/24/2012 08:11 PM, Curtis Villamizar wrote: > In message <5060BDC7.6020403@freedesktop.org> > Jim Gettys writes: > >> On 09/24/2012 03:17 PM, Don Sturek wrote: >>> Hi Curtis, >>> >>> Here is the use case: >>> 1) Customer has a legacy AP in their house >>> 2) Customer brings home new devices supporting IPv6 (which are designed >>> to communicate only with other IPv6 based devices in the home) >>> 3) The only way these new devices can communicate is through address >>> assignment using SLAAC and then some discovery method the two new devices >>> support (without support from the AP). Here these devices are assuming >>> bridging through the AP...... >> >> And since current legacy AP's all bridge, we win (even though we need to >> route in the future). > Jim, > > The point was how do you get local IPv6 within the home with the > legacy AP that does only IPv4 and just does bridging of IPv6. First > of all you have no subnets. There is no CER to do DHCPv6. > > In this case you use link local or if everything has a MAC you can use > ULA based on the MAC addressses. > >>> Placing a requirement that every customer who buys a new IPv6 device, >>> intended to communicate only with other IPv6 devices in the home, will >>> require a forklift upgrade of a deployed network in order to work will not >>> be popular. >> >> Good point. > But invalid. The use case Don gave would still work fine. Only GUA > addresses are affected. > >> I loathe DHCP (of any sort) *for basic address assignment, anyway* in >> the home environment. >> >> The loathing comes from the exquisite pain of suffering with a flaky >> home network for several months, before realising I had a rogue DHCP >> server somewhere on my network (from wireshark). I then had to take the >> mac address, figure out who may have manufactured some device from that >> information, and finally figured out the little VOIP ATA adaptor I had >> been given liked to do DHCP. > It did DHCP on the *WAN side*? You didn't put the rest of your > network behind the VOIP box on the LAN side I hope. It did dhcp on my network; evil. Only had one ethernet port, IIRC. > >> This was by far the hardest debugging I've had to do in my home network >> in normal operation. >> >> This is well beyond normal home debugging capability of consumers. >> - Jim > We all have plenty of crappy IPv4 product horror stories. My VOIP > phone locked up now and then and I figured out that if the call lasted > longer than the DHCPv4 lease, then it lost the least because it didn't > try to renew it. Not only did the call drop, but the device locked > up. The first solution was to reboot it now and then. The answer was > to configure a fixed address. I was lucky to figure it out before my > wife threw the phone through a window. For all I know a later > firmware upgrade might have fixed it. VOIP might be more popular if > VOIP phones under $600 worked reasonably well. > > Both nice stories, but both are DHCPv4 related and have nothing at all > to do with SLAAC. My point is I don't like to depend on DHCP to get my addresses, as it seems lots of people add them as a "feature" to this or that home device, setting up for unhappy broken networks. And it's really painful to debug when you can't even access the network at all (which is the failure mode that was happening to me). - Jim > > Curtis > >>> Don >>> >>> >>> >>> >>> On 9/24/12 11:49 AM, "Curtis Villamizar" wrote: >>> >>>> In message >>>> Don Sturek writes: >>>> >>>>> Hi Curtis, >>>>> >>>>> SLAAC not working is a major problem. >>>>> >>>>> Don >>>> Don, >>>> >>>> Why? This is an assertion without basis as far as I am concerned. >>>> Except CGA there is nothing that breaks without SLAAC. Joel brought >>>> up ILNP in private email, but I beleive ILNP can also work as the >>>> constraints in ILNP are in the ILNP identifier which is not the same >>>> as the interface address in ILNP for which there is no constraint. >>>> >>>> I have subnets running fine using a few /112 allocated from within a >>>> /64 with fixed addresses on rack mount hosts and desktops and DHCPv6 >>>> for dynamic allocations for laptops. It works fine. Link local >>>> addresses are all that is needed to get DHCPv6 to work. No host ever >>>> receives a RA since my routers won't give them one, so no host ever >>>> tries to generate an address using SLAAC. The only constraint is that >>>> any host connecting to my Ethernet or wireless must run a DHCP client >>>> and if they want an IPv6 GUA must run a DHCPv6 client. DHCPv4 and >>>> DHCPv6 servers are available in every subnet except one GbE subnet in >>>> the rack and to a few hosts in my home office. >>>> >>>> So as far as I am concerned we have an assertion that no SLAAC is a >>>> problem and existance proof that it is not. Beside CGA and requiring >>>> that hosts run DHCPv6 if they want an IPv6 GUA, what can I not support >>>> on these /112 subnets? >>>> >>>> Curtis >>>> >>>> >>>>> On 9/23/12 4:09 PM, "Curtis Villamizar" wrote: >>>>> >>>>>> In message <505E83F6.3030900@joelhalpern.com> >>>>>> "Joel M. Halpern" writes: >>>>>> >>>>>>> Since you invited flames... >>>>>>> >>>>>>> The argument on /64 as the longest prefix is not that it is magically >>>>>>> unnatural. >>>>>>> Rather, it is that there are a number of current and evolving >>>>> protocols >>>>>>> that depend upon that /64. The obvious example is that SLAAC does >>>>> not >>>>>>> work if subnets are longer than /64. >>>>>>> >>>>>>> The rules in this regard are written into approved RFCs. If homenet >>>>>>> wants to change that, it really needs to go to 6man with a strong >>>>> case. >>>>>>> (for point-to-point inter-router links this was recently relaxed. >>>>>>> >>>>>>> At the same time, andy operator who insists on giving homes a /64 is >>>>>>> being inappropriately restrictive. Homenet should say that, rather >>>>>>> than >>>>>>> trying to change the IPv6 architecture. >>>>>>> >>>>>>> Yours, >>>>>>> Joel >>>>>> Joel, >>>>>> >>>>>> I don't consider your email a flame at all. Thanks for responding. >>>>>> >>>>>> SLAAC (which I am not at a fan of) won't work but DHCPv6 will so IMHO >>>>>> no loss. CGA also won't work but then again I've also never been a >>>>>> fan of security half measures. Yes anti-spoofing without prior >>>>>> exchange of a key is nice, but no reasonable authorization could be >>>>>> based on CGA without also exchanging some sort of key or cert and at >>>>>> that point the CGA as a public key is redundant. >>>>>> >>>>>> If SLAAC and CGA are the only things that break *and* providers do >>>>>> hand out prefixes that are too small, then /64 prefixes will have to >>>>>> be subdivided. >>>>>> >>>>>> So a question for you is what else if anything will break? >>>>>> >>>>>> I also understand that you are suggesting that this be taken to 6man. >>>>>> That is a good suggestion. >>>>>> >>>>>> Curtis >>>>>> >>>>>> >>>>>>> On 9/22/2012 11:30 PM, Curtis Villamizar wrote: >>>>>>>> 12. This is sure to be controversial. I pointed out that using >>>>>>>> subnets longer than /64 is OK as long as they are not leaked >>>>>>>> into global routing. Please read the text and changes >>>>> before >>>>>>>> exploding on this topic. It may be necessary to subnet a >>>>> /64 >>>>>>> if >>>>>>>> that is all a provider will give you and you need subnets. >>>>> It >>>>>>>> does work and it is no more unnatural than subnetting a >>>>> class-A >>>>>>>> network would be in 1990. It means using DHCPv6 and not >>>>> using >>>>>>>> RA prefixes for GUA (otherwise SLAAC implementations would >>>>>>>> likely try to use the whole bottom 64). > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From d.sturek@att.net Mon Sep 24 18:01: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 88F441F0CB4 for ; Mon, 24 Sep 2012 18:01:40 -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 a7hwCEzDtz75 for ; Mon, 24 Sep 2012 18:01:39 -0700 (PDT) Received: from nm15-vm0.bullet.mail.sp2.yahoo.com (nm15-vm0.bullet.mail.sp2.yahoo.com [98.139.91.208]) by ietfa.amsl.com (Postfix) with SMTP id A9DEB1F0CA8 for ; Mon, 24 Sep 2012 18:01:39 -0700 (PDT) Received: from [98.139.91.63] by nm15.bullet.mail.sp2.yahoo.com with NNFMP; 25 Sep 2012 01:01:34 -0000 Received: from [66.94.237.103] by tm3.bullet.mail.sp2.yahoo.com with NNFMP; 25 Sep 2012 01:01:34 -0000 Received: from [127.0.0.1] by omp1008.access.mail.mud.yahoo.com with NNFMP; 25 Sep 2012 01:01:34 -0000 X-Yahoo-Newman-Id: 385261.60028.bm@omp1008.access.mail.mud.yahoo.com Received: (qmail 88747 invoked from network); 25 Sep 2012 01:01:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1348534894; bh=NEmRE46k/tbHAnU1QZk9xrqTgiXhmdrrIWlRdxvXnms=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=iNXC+L6P0AyLStTjouGRo85Ow1G29pGI+tbdtSUQkoIS9RWrFG0k6p5HxpCutdaXr8Q0xxHCjvjErvO2E6YjtSLUhN0PECj6lswzLwG8PmFNG3tzcM9y3cDVSQJQubHMxF6xyT5mYqG4rjThk/pE5wiiCRL+a4pJTOvFXTKaslo= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: WFutdvYVM1kAV8L_P3DmYHFnKVVffxUT5AZ2dkiTcaiRDqv f5wsIQalYrBYsDnT_VSZHW408pUG5p7Jf5cmYnHFC4KSABe2T8sj0g6cY78m PbjlY7pHjJz1eRyrrs0QJXZeeKrwcxxmLyPC4mIFlEcK4P2ETRWmF1NY2mhG OdwbPwH8kXQ5x04f0iPfp1rdy5CHfGjjI6zDzMWWfZacq3lB9bPkPHHxTuGv c59iGurdIZRCP6TCWbN7H6pMGBDb8mTIwg9bTX6bodv4KARE7XhjLpNp87CB ZadV95l0LzT5AQlVT8o0uiSo9_Zs.lVDbitRcrbtVG1fAFenska2_OEmUkNF aVZzhLrDFeXHFZaCX2kPAkEStjOmRfDH6PkKW0rmz_lkYXmTL.UOQLN89eq1 Mu.DeTVXRiycJepwzpsFvfQZjNRT9aR7z0dCFYqwoPC3_741jNKI9JlOcv83 sxspK97q6T2ciN_2nOqY4ePQHU31eYeqiKRqT3Xc56Jie X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [192.168.0.197] (d.sturek@69.108.51.128 with login) by smtp107.sbc.mail.mud.yahoo.com with SMTP; 24 Sep 2012 18:01:33 -0700 PDT User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Mon, 24 Sep 2012 18:01:29 -0700 From: Don Sturek To: , Jim Gettys Message-ID: Thread-Topic: [homenet] draft-ietf-homenet-arch-04 In-Reply-To: <201209250011.q8P0B12L065909@gateway1.orleans.occnc.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: homenet@ietf.org, "Joel M. Halpern" Subject: Re: [homenet] draft-ietf-homenet-arch-04 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 01:01:40 -0000 Hi Curtis, I would expect most Wi-Fi AP manufacturers to support the same address assignment they do today (ie, manual assignment and DHCP). I would also expect as more IPv6 deployments happen that SLAAC will also be supported (and, yes, even for GUA). For the types of devices which will be added to Wi-Fi networks in the future (eg, headless devices like appliances, thermostats, etc.) that the preferred address assignment will be SLAAC and DHCPv6 (and, yes, I purposely did not remove SLAAC.....) Don On 9/24/12 5:11 PM, "Curtis Villamizar" wrote: > >In message <5060BDC7.6020403@freedesktop.org> >Jim Gettys writes: > >> On 09/24/2012 03:17 PM, Don Sturek wrote: >> > Hi Curtis, >> > >> > Here is the use case: >> > 1) Customer has a legacy AP in their house >> > 2) Customer brings home new devices supporting IPv6 (which are >>designed >> > to communicate only with other IPv6 based devices in the home) >> > 3) The only way these new devices can communicate is through address >> > assignment using SLAAC and then some discovery method the two new >>devices >> > support (without support from the AP). Here these devices are >>assuming >> > bridging through the AP...... >> >> And since current legacy AP's all bridge, we win (even though we need to >> route in the future). > >Jim, > >The point was how do you get local IPv6 within the home with the >legacy AP that does only IPv4 and just does bridging of IPv6. First >of all you have no subnets. There is no CER to do DHCPv6. > >In this case you use link local or if everything has a MAC you can use >ULA based on the MAC addressses. > >> > Placing a requirement that every customer who buys a new IPv6 device, >> > intended to communicate only with other IPv6 devices in the home, will >> > require a forklift upgrade of a deployed network in order to work >>will not >> > be popular. >> >> Good point. > >But invalid. The use case Don gave would still work fine. Only GUA >addresses are affected. > >> I loathe DHCP (of any sort) *for basic address assignment, anyway* in >> the home environment. >> >> The loathing comes from the exquisite pain of suffering with a flaky >> home network for several months, before realising I had a rogue DHCP >> server somewhere on my network (from wireshark). I then had to take the >> mac address, figure out who may have manufactured some device from that >> information, and finally figured out the little VOIP ATA adaptor I had >> been given liked to do DHCP. > >It did DHCP on the *WAN side*? You didn't put the rest of your >network behind the VOIP box on the LAN side I hope. > >> This was by far the hardest debugging I've had to do in my home network >> in normal operation. >> >> This is well beyond normal home debugging capability of consumers. >> - Jim > >We all have plenty of crappy IPv4 product horror stories. My VOIP >phone locked up now and then and I figured out that if the call lasted >longer than the DHCPv4 lease, then it lost the least because it didn't >try to renew it. Not only did the call drop, but the device locked >up. The first solution was to reboot it now and then. The answer was >to configure a fixed address. I was lucky to figure it out before my >wife threw the phone through a window. For all I know a later >firmware upgrade might have fixed it. VOIP might be more popular if >VOIP phones under $600 worked reasonably well. > >Both nice stories, but both are DHCPv4 related and have nothing at all >to do with SLAAC. > >Curtis > >> > Don >> > >> > >> > >> > >> > On 9/24/12 11:49 AM, "Curtis Villamizar" wrote: >> > >> >> In message >> >> Don Sturek writes: >> >> >> >>> Hi Curtis, >> >>> >> >>> SLAAC not working is a major problem. >> >>> >> >>> Don >> >> >> >> Don, >> >> >> >> Why? This is an assertion without basis as far as I am concerned. >> >> Except CGA there is nothing that breaks without SLAAC. Joel brought >> >> up ILNP in private email, but I beleive ILNP can also work as the >> >> constraints in ILNP are in the ILNP identifier which is not the same >> >> as the interface address in ILNP for which there is no constraint. >> >> >> >> I have subnets running fine using a few /112 allocated from within a >> >> /64 with fixed addresses on rack mount hosts and desktops and DHCPv6 >> >> for dynamic allocations for laptops. It works fine. Link local >> >> addresses are all that is needed to get DHCPv6 to work. No host ever >> >> receives a RA since my routers won't give them one, so no host ever >> >> tries to generate an address using SLAAC. The only constraint is >>that >> >> any host connecting to my Ethernet or wireless must run a DHCP client >> >> and if they want an IPv6 GUA must run a DHCPv6 client. DHCPv4 and >> >> DHCPv6 servers are available in every subnet except one GbE subnet in >> >> the rack and to a few hosts in my home office. >> >> >> >> So as far as I am concerned we have an assertion that no SLAAC is a >> >> problem and existance proof that it is not. Beside CGA and requiring >> >> that hosts run DHCPv6 if they want an IPv6 GUA, what can I not >>support >> >> on these /112 subnets? >> >> >> >> Curtis >> >> >> >> >> >>> On 9/23/12 4:09 PM, "Curtis Villamizar" wrote: >> >>> >> >>>> In message <505E83F6.3030900@joelhalpern.com> >> >>>> "Joel M. Halpern" writes: >> >>>> >> >>>>> Since you invited flames... >> >>>>> >> >>>>> The argument on /64 as the longest prefix is not that it is >>magically >> >>>>> unnatural. >> >>>>> Rather, it is that there are a number of current and evolving >> >>> protocols >> >>>>> that depend upon that /64. The obvious example is that SLAAC does >> >>> not >> >>>>> work if subnets are longer than /64. >> >>>>> >> >>>>> The rules in this regard are written into approved RFCs. If >>homenet >> >>>>> wants to change that, it really needs to go to 6man with a strong >> >>> case. >> >>>>> (for point-to-point inter-router links this was recently >>relaxed. >> >>>>> >> >>>>> At the same time, andy operator who insists on giving homes a /64 >>is >> >>>>> being inappropriately restrictive. Homenet should say that, >>rather >> >>>>> than >> >>>>> trying to change the IPv6 architecture. >> >>>>> >> >>>>> Yours, >> >>>>> Joel >> >>>> Joel, >> >>>> >> >>>> I don't consider your email a flame at all. Thanks for responding. >> >>>> >> >>>> SLAAC (which I am not at a fan of) won't work but DHCPv6 will so >>IMHO >> >>>> no loss. CGA also won't work but then again I've also never been a >> >>>> fan of security half measures. Yes anti-spoofing without prior >> >>>> exchange of a key is nice, but no reasonable authorization could be >> >>>> based on CGA without also exchanging some sort of key or cert and >>at >> >>>> that point the CGA as a public key is redundant. >> >>>> >> >>>> If SLAAC and CGA are the only things that break *and* providers do >> >>>> hand out prefixes that are too small, then /64 prefixes will have >>to >> >>>> be subdivided. >> >>>> >> >>>> So a question for you is what else if anything will break? >> >>>> >> >>>> I also understand that you are suggesting that this be taken to >>6man. >> >>>> That is a good suggestion. >> >>>> >> >>>> Curtis >> >>>> >> >>>> >> >>>>> On 9/22/2012 11:30 PM, Curtis Villamizar wrote: >> >>>>>> 12. This is sure to be controversial. I pointed out that >>using >> >>>>>> subnets longer than /64 is OK as long as they are not >>leaked >> >>>>>> into global routing. Please read the text and changes >> >>> before >> >>>>>> exploding on this topic. It may be necessary to subnet a >> >>> /64 >> >>>>> if >> >>>>>> that is all a provider will give you and you need subnets. >> >>> It >> >>>>>> does work and it is no more unnatural than subnetting a >> >>> class-A >> >>>>>> network would be in 1990. It means using DHCPv6 and not >> >>> using >> >>>>>> RA prefixes for GUA (otherwise SLAAC implementations would >> >>>>>> likely try to use the whole bottom 64). >_______________________________________________ >homenet mailing list >homenet@ietf.org >https://www.ietf.org/mailman/listinfo/homenet From curtis@occnc.com Mon Sep 24 18:53: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 1C77E21F8605 for ; Mon, 24 Sep 2012 18:53:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.125, 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 j5WI-hSPZ7Wn for ; Mon, 24 Sep 2012 18:53:09 -0700 (PDT) Received: from gateway1.orleans.occnc.com (gateway1.orleans.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id C7C6421F8843 for ; Mon, 24 Sep 2012 18:53:08 -0700 (PDT) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id q8P1qEnX066426; Mon, 24 Sep 2012 21:52:15 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201209250152.q8P1qEnX066426@gateway1.orleans.occnc.com> To: Don Sturek From: Curtis Villamizar In-reply-to: Your message of "Mon, 24 Sep 2012 18:01:29 PDT." Date: Mon, 24 Sep 2012 21:52:14 -0400 Cc: homenet@ietf.org, "Joel M. Halpern" , Jim Gettys , curtis@occnc.com Subject: Re: [homenet] draft-ietf-homenet-arch-04 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, 25 Sep 2012 01:53:10 -0000 In message Don Sturek writes: > Hi Curtis, > > I would expect most Wi-Fi AP manufacturers to support the same address > assignment they do today (ie, manual assignment and DHCP). I would > also expect as more IPv6 deployments happen that SLAAC will also be > supported (and, yes, even for GUA). > > For the types of devices which will be added to Wi-Fi networks in the > future (eg, headless devices like appliances, thermostats, etc.) that > the preferred address assignment will be SLAAC and DHCPv6 (and, yes, I > purposely did not remove SLAAC.....) > > Don Don, We seem to be talking past each other so let me again try to be clear. What every host does is: if it has no MAC: pick a random link local (not ULA) address else use the MAC to create a ULA address run DAD to make sure no one else has same address send a RS if it gets RA use the RA prefix for SLAAC else time out and don't bother with SLAAC then hopefully the host also does the following: send DHCPv6 client request if response it has yet another address to pick from if it got one using SLAAC else time out and get nothing from DHCPv6 Note: new extensions to DHCPv6 allow the host to tell DHCPv6 server the address that it already has (from SLAAC). If as in the case of your Wi-Fi with a bridging AP example, there is no router to give it an DHCPv6 the link local or ULA addresses are still there and still usable. There is also no router to give it an RA response so it has no SLAAC assigned address and no DHCPv6 assigned address. That is the end of your example. If there is a router then there is something that can hand out a RA or DHCPv6 response. In the case were there exists multiple subnets and the CER has been granted a /64 (or too few /64s to handle the number of subnets), then: it can use RA with /64 on some subnets and give them GUA addresses and some subnets have no access outside the homenet --or-- it can not use RA (and therefore prevent SLAAC from being used) and hand out DHCPv6 addresses and make use of prefixes longer than /64. This prevents the use of CGA but get connectivity to the entire homenet. If every consumer oriented provider is willing to allocate prefixes shorter than /64 on request to home users, then the above situation never occurs. If it does, my argument is that the second option above is better than the first. Curtis > On 9/24/12 5:11 PM, "Curtis Villamizar" wrote: > > > > >In message <5060BDC7.6020403@freedesktop.org> > >Jim Gettys writes: > > > >> On 09/24/2012 03:17 PM, Don Sturek wrote: > >> > Hi Curtis, > >> > > >> > Here is the use case: > >> > 1) Customer has a legacy AP in their house > >> > 2) Customer brings home new devices supporting IPv6 (which are > >>designed > >> > to communicate only with other IPv6 based devices in the home) > >> > 3) The only way these new devices can communicate is through address > >> > assignment using SLAAC and then some discovery method the two new > >>devices > >> > support (without support from the AP). Here these devices are > >>assuming > >> > bridging through the AP...... > >> > >> And since current legacy AP's all bridge, we win (even though we need to > >> route in the future). > > > >Jim, > > > >The point was how do you get local IPv6 within the home with the > >legacy AP that does only IPv4 and just does bridging of IPv6. First > >of all you have no subnets. There is no CER to do DHCPv6. > > > >In this case you use link local or if everything has a MAC you can use > >ULA based on the MAC addressses. > > > >> > Placing a requirement that every customer who buys a new IPv6 device, > >> > intended to communicate only with other IPv6 devices in the home, will > >> > require a forklift upgrade of a deployed network in order to work > >>will not > >> > be popular. > >> > >> Good point. > > > >But invalid. The use case Don gave would still work fine. Only GUA > >addresses are affected. > > > >> I loathe DHCP (of any sort) *for basic address assignment, anyway* in > >> the home environment. > >> > >> The loathing comes from the exquisite pain of suffering with a flaky > >> home network for several months, before realising I had a rogue DHCP > >> server somewhere on my network (from wireshark). I then had to take the > >> mac address, figure out who may have manufactured some device from that > >> information, and finally figured out the little VOIP ATA adaptor I had > >> been given liked to do DHCP. > > > >It did DHCP on the *WAN side*? You didn't put the rest of your > >network behind the VOIP box on the LAN side I hope. > > > >> This was by far the hardest debugging I've had to do in my home network > >> in normal operation. > >> > >> This is well beyond normal home debugging capability of consumers. > >> - Jim > > > >We all have plenty of crappy IPv4 product horror stories. My VOIP > >phone locked up now and then and I figured out that if the call lasted > >longer than the DHCPv4 lease, then it lost the least because it didn't > >try to renew it. Not only did the call drop, but the device locked > >up. The first solution was to reboot it now and then. The answer was > >to configure a fixed address. I was lucky to figure it out before my > >wife threw the phone through a window. For all I know a later > >firmware upgrade might have fixed it. VOIP might be more popular if > >VOIP phones under $600 worked reasonably well. > > > >Both nice stories, but both are DHCPv4 related and have nothing at all > >to do with SLAAC. > > > >Curtis > > > >> > Don > >> > > >> > > >> > > >> > > >> > On 9/24/12 11:49 AM, "Curtis Villamizar" wrote: > >> > > >> >> In message > >> >> Don Sturek writes: > >> >> > >> >>> Hi Curtis, > >> >>> > >> >>> SLAAC not working is a major problem. > >> >>> > >> >>> Don > >> >> > >> >> Don, > >> >> > >> >> Why? This is an assertion without basis as far as I am concerned. > >> >> Except CGA there is nothing that breaks without SLAAC. Joel brought > >> >> up ILNP in private email, but I beleive ILNP can also work as the > >> >> constraints in ILNP are in the ILNP identifier which is not the same > >> >> as the interface address in ILNP for which there is no constraint. > >> >> > >> >> I have subnets running fine using a few /112 allocated from within a > >> >> /64 with fixed addresses on rack mount hosts and desktops and DHCPv6 > >> >> for dynamic allocations for laptops. It works fine. Link local > >> >> addresses are all that is needed to get DHCPv6 to work. No host ever > >> >> receives a RA since my routers won't give them one, so no host ever > >> >> tries to generate an address using SLAAC. The only constraint is > >>that > >> >> any host connecting to my Ethernet or wireless must run a DHCP client > >> >> and if they want an IPv6 GUA must run a DHCPv6 client. DHCPv4 and > >> >> DHCPv6 servers are available in every subnet except one GbE subnet in > >> >> the rack and to a few hosts in my home office. > >> >> > >> >> So as far as I am concerned we have an assertion that no SLAAC is a > >> >> problem and existance proof that it is not. Beside CGA and requiring > >> >> that hosts run DHCPv6 if they want an IPv6 GUA, what can I not > >>support > >> >> on these /112 subnets? > >> >> > >> >> Curtis > >> >> > >> >> > >> >>> On 9/23/12 4:09 PM, "Curtis Villamizar" wrote: > >> >>> > >> >>>> In message <505E83F6.3030900@joelhalpern.com> > >> >>>> "Joel M. Halpern" writes: > >> >>>> > >> >>>>> Since you invited flames... > >> >>>>> > >> >>>>> The argument on /64 as the longest prefix is not that it is > >>magically > >> >>>>> unnatural. > >> >>>>> Rather, it is that there are a number of current and evolving > >> >>> protocols > >> >>>>> that depend upon that /64. The obvious example is that SLAAC does > >> >>> not > >> >>>>> work if subnets are longer than /64. > >> >>>>> > >> >>>>> The rules in this regard are written into approved RFCs. If > >>homenet > >> >>>>> wants to change that, it really needs to go to 6man with a strong > >> >>> case. > >> >>>>> (for point-to-point inter-router links this was recently > >>relaxed. > >> >>>>> > >> >>>>> At the same time, andy operator who insists on giving homes a /64 > >>is > >> >>>>> being inappropriately restrictive. Homenet should say that, > >>rather > >> >>>>> than > >> >>>>> trying to change the IPv6 architecture. > >> >>>>> > >> >>>>> Yours, > >> >>>>> Joel > >> >>>> Joel, > >> >>>> > >> >>>> I don't consider your email a flame at all. Thanks for responding. > >> >>>> > >> >>>> SLAAC (which I am not at a fan of) won't work but DHCPv6 will so > >>IMHO > >> >>>> no loss. CGA also won't work but then again I've also never been a > >> >>>> fan of security half measures. Yes anti-spoofing without prior > >> >>>> exchange of a key is nice, but no reasonable authorization could be > >> >>>> based on CGA without also exchanging some sort of key or cert and > >>at > >> >>>> that point the CGA as a public key is redundant. > >> >>>> > >> >>>> If SLAAC and CGA are the only things that break *and* providers do > >> >>>> hand out prefixes that are too small, then /64 prefixes will have > >>to > >> >>>> be subdivided. > >> >>>> > >> >>>> So a question for you is what else if anything will break? > >> >>>> > >> >>>> I also understand that you are suggesting that this be taken to > >>6man. > >> >>>> That is a good suggestion. > >> >>>> > >> >>>> Curtis > >> >>>> > >> >>>> > >> >>>>> On 9/22/2012 11:30 PM, Curtis Villamizar wrote: > >> >>>>>> 12. This is sure to be controversial. I pointed out that > >>using > >> >>>>>> subnets longer than /64 is OK as long as they are not > >>leaked > >> >>>>>> into global routing. Please read the text and changes > >> >>> before > >> >>>>>> exploding on this topic. It may be necessary to subnet a > >> >>> /64 > >> >>>>> if > >> >>>>>> that is all a provider will give you and you need subnets. > >> >>> It > >> >>>>>> does work and it is no more unnatural than subnetting a > >> >>> class-A > >> >>>>>> network would be in 1990. It means using DHCPv6 and not > >> >>> using > >> >>>>>> RA prefixes for GUA (otherwise SLAAC implementations would > >> >>>>>> likely try to use the whole bottom 64). > >_______________________________________________ > >homenet mailing list > >homenet@ietf.org > >https://www.ietf.org/mailman/listinfo/homenet > > From d.sturek@att.net Mon Sep 24 19:42: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 BB5AF21F88D6 for ; Mon, 24 Sep 2012 19:42:08 -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 r9-FgwAjn35N for ; Mon, 24 Sep 2012 19:42:07 -0700 (PDT) Received: from nm38.bullet.mail.ne1.yahoo.com (nm38.bullet.mail.ne1.yahoo.com [98.138.229.31]) by ietfa.amsl.com (Postfix) with SMTP id 5C19F21F88A3 for ; Mon, 24 Sep 2012 19:42:07 -0700 (PDT) Received: from [98.138.90.57] by nm38.bullet.mail.ne1.yahoo.com with NNFMP; 25 Sep 2012 02:42:04 -0000 Received: from [66.94.237.99] by tm10.bullet.mail.ne1.yahoo.com with NNFMP; 25 Sep 2012 02:42:04 -0000 Received: from [127.0.0.1] by omp1004.access.mail.mud.yahoo.com with NNFMP; 25 Sep 2012 02:42:03 -0000 X-Yahoo-Newman-Id: 967007.45929.bm@omp1004.access.mail.mud.yahoo.com Received: (qmail 64774 invoked from network); 25 Sep 2012 02:42:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1348540923; bh=zOvtFy0AntWIa2NUaspEnFYatIie1SmUDng5kvhZ9S0=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=Qx93q5Uv9TrCsy9kOh0hOSd94dARfOyNrpJ2ACBEfbjVs5rNvvO0JN1E5rfah6hrDl8s7Hzn3uZglzfztH2b4USjIjs0yn5VlRnPO1ZQTnNLgLz1Xps9H7I2c874QDw/eYH6nf+ffkOIMb6QcwW5V50z57qdQqxhZP7DS8Z79sw= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: KIlQH1wVM1lzw3fPaqv6YAbPyvUAWHT63fYVzet5Ai4tIoc .rPGMadI5JoY1LJYWkGQV_e0ExxMOzuLdERAUoYcngBNEn6Iv6ESv3uBXazW vhDcnhetH_HMAtyVldq9ptD9mCNOZb8GRg8._0sS692Jek7xKCZxPW04O4yR VNE8.n5JzYjrma6WkeUeq9pQcCoxVznlDRX.LJwceN2COSvZWgk.hu1WznCo 40HRAg2QktK4nF_Tb14M5Op67NBUyGkgl929XgpbCBEaCxqertKS1kbGp.XS Pf.9vcUUZY8Wu5g0wEQu78ZUUh5Cf_U7NYB7tspe1.uhz_Zwyt.eZFdoPXU6 fLzHjACThmub64bWnldhjH0wrq4cjB3CLNS6F346yDILyPe6ll_mr5O6urZi rHpEOSOCv2kTs220fZyYR.HFdsOJlqPv9EMLpptFpwE_ZfTLd19W6ziiA.WG 9z3fTo5m84bmLKTD7zRmntsK4mt671G9MPG.RYt5M2Y9MWhg62SjLtSyv1T7 LHpA3LHqul1kw3ONuLXptiyxRYtcFTg-- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [192.168.0.197] (d.sturek@69.108.51.128 with login) by smtp107.sbc.mail.mud.yahoo.com with SMTP; 24 Sep 2012 19:42:03 -0700 PDT User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Mon, 24 Sep 2012 19:42:00 -0700 From: Don Sturek To: Message-ID: Thread-Topic: [homenet] draft-ietf-homenet-arch-04 In-Reply-To: <201209250152.q8P1qEnX066426@gateway1.orleans.occnc.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: homenet@ietf.org, "Joel M. Halpern" , Jim Gettys Subject: Re: [homenet] draft-ietf-homenet-arch-04 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 02:42:08 -0000 Hi Curtis, I think the difficulty is each device cannot "use the MAC to create a ULA address". Some authoritative device in the network (eg, the AP) must create the ULA prefix. If a ULA prefix is not present because the AP is a legacy device not capable of providing a ULA prefix, the STA devices must use link locals only. Don On 9/24/12 6:52 PM, "Curtis Villamizar" wrote: > >In message >Don Sturek writes: > >> Hi Curtis, >> >> I would expect most Wi-Fi AP manufacturers to support the same address >> assignment they do today (ie, manual assignment and DHCP). I would >> also expect as more IPv6 deployments happen that SLAAC will also be >> supported (and, yes, even for GUA). >> >> For the types of devices which will be added to Wi-Fi networks in the >> future (eg, headless devices like appliances, thermostats, etc.) that >> the preferred address assignment will be SLAAC and DHCPv6 (and, yes, I >> purposely did not remove SLAAC.....) >> >> Don > > >Don, > >We seem to be talking past each other so let me again try to be clear. > >What every host does is: > > if it has no MAC: > pick a random link local (not ULA) address > else > use the MAC to create a ULA address > run DAD to make sure no one else has same address > > send a RS > > if it gets RA > use the RA prefix for SLAAC > else > time out and don't bother with SLAAC > >then hopefully the host also does the following: > > send DHCPv6 client request > > if response > it has yet another address to pick from if it got one using SLAAC > else > time out and get nothing from DHCPv6 > >Note: new extensions to DHCPv6 allow the host to tell DHCPv6 server >the address that it already has (from SLAAC). > >If as in the case of your Wi-Fi with a bridging AP example, there is >no router to give it an DHCPv6 the link local or ULA addresses are >still there and still usable. There is also no router to give it an >RA response so it has no SLAAC assigned address and no DHCPv6 assigned >address. > >That is the end of your example. > >If there is a router then there is something that can hand out a RA or >DHCPv6 response. > >In the case were there exists multiple subnets and the CER has been >granted a /64 (or too few /64s to handle the number of subnets), then: > > it can use RA with /64 on some subnets and give them GUA addresses > and some subnets have no access outside the homenet > > --or-- > > it can not use RA (and therefore prevent SLAAC from being used) and > hand out DHCPv6 addresses and make use of prefixes longer than /64. > This prevents the use of CGA but get connectivity to the entire > homenet. > >If every consumer oriented provider is willing to allocate prefixes >shorter than /64 on request to home users, then the above situation >never occurs. If it does, my argument is that the second option above >is better than the first. > >Curtis > > >> On 9/24/12 5:11 PM, "Curtis Villamizar" wrote: >> >> > >> >In message <5060BDC7.6020403@freedesktop.org> >> >Jim Gettys writes: >> > >> >> On 09/24/2012 03:17 PM, Don Sturek wrote: >> >> > Hi Curtis, >> >> > >> >> > Here is the use case: >> >> > 1) Customer has a legacy AP in their house >> >> > 2) Customer brings home new devices supporting IPv6 (which are >> >>designed >> >> > to communicate only with other IPv6 based devices in the home) >> >> > 3) The only way these new devices can communicate is through >>address >> >> > assignment using SLAAC and then some discovery method the two new >> >>devices >> >> > support (without support from the AP). Here these devices are >> >>assuming >> >> > bridging through the AP...... >> >> >> >> And since current legacy AP's all bridge, we win (even though we >>need to >> >> route in the future). >> > >> >Jim, >> > >> >The point was how do you get local IPv6 within the home with the >> >legacy AP that does only IPv4 and just does bridging of IPv6. First >> >of all you have no subnets. There is no CER to do DHCPv6. >> > >> >In this case you use link local or if everything has a MAC you can use >> >ULA based on the MAC addressses. >> > >> >> > Placing a requirement that every customer who buys a new IPv6 >>device, >> >> > intended to communicate only with other IPv6 devices in the home, >>will >> >> > require a forklift upgrade of a deployed network in order to work >> >>will not >> >> > be popular. >> >> >> >> Good point. >> > >> >But invalid. The use case Don gave would still work fine. Only GUA >> >addresses are affected. >> > >> >> I loathe DHCP (of any sort) *for basic address assignment, anyway* in >> >> the home environment. >> >> >> >> The loathing comes from the exquisite pain of suffering with a flaky >> >> home network for several months, before realising I had a rogue DHCP >> >> server somewhere on my network (from wireshark). I then had to take >>the >> >> mac address, figure out who may have manufactured some device from >>that >> >> information, and finally figured out the little VOIP ATA adaptor I >>had >> >> been given liked to do DHCP. >> > >> >It did DHCP on the *WAN side*? You didn't put the rest of your >> >network behind the VOIP box on the LAN side I hope. >> > >> >> This was by far the hardest debugging I've had to do in my home >>network >> >> in normal operation. >> >> >> >> This is well beyond normal home debugging capability of consumers. >> >> - Jim >> > >> >We all have plenty of crappy IPv4 product horror stories. My VOIP >> >phone locked up now and then and I figured out that if the call lasted >> >longer than the DHCPv4 lease, then it lost the least because it didn't >> >try to renew it. Not only did the call drop, but the device locked >> >up. The first solution was to reboot it now and then. The answer was >> >to configure a fixed address. I was lucky to figure it out before my >> >wife threw the phone through a window. For all I know a later >> >firmware upgrade might have fixed it. VOIP might be more popular if >> >VOIP phones under $600 worked reasonably well. >> > >> >Both nice stories, but both are DHCPv4 related and have nothing at all >> >to do with SLAAC. >> > >> >Curtis >> > >> >> > Don >> >> > >> >> > >> >> > >> >> > >> >> > On 9/24/12 11:49 AM, "Curtis Villamizar" wrote: >> >> > >> >> >> In message >> >> >> Don Sturek writes: >> >> >> >> >> >>> Hi Curtis, >> >> >>> >> >> >>> SLAAC not working is a major problem. >> >> >>> >> >> >>> Don >> >> >> >> >> >> Don, >> >> >> >> >> >> Why? This is an assertion without basis as far as I am concerned. >> >> >> Except CGA there is nothing that breaks without SLAAC. Joel >>brought >> >> >> up ILNP in private email, but I beleive ILNP can also work as the >> >> >> constraints in ILNP are in the ILNP identifier which is not the >>same >> >> >> as the interface address in ILNP for which there is no constraint. >> >> >> >> >> >> I have subnets running fine using a few /112 allocated from >>within a >> >> >> /64 with fixed addresses on rack mount hosts and desktops and >>DHCPv6 >> >> >> for dynamic allocations for laptops. It works fine. Link local >> >> >> addresses are all that is needed to get DHCPv6 to work. No host >>ever >> >> >> receives a RA since my routers won't give them one, so no host >>ever >> >> >> tries to generate an address using SLAAC. The only constraint is >> >>that >> >> >> any host connecting to my Ethernet or wireless must run a DHCP >>client >> >> >> and if they want an IPv6 GUA must run a DHCPv6 client. DHCPv4 and >> >> >> DHCPv6 servers are available in every subnet except one GbE >>subnet in >> >> >> the rack and to a few hosts in my home office. >> >> >> >> >> >> So as far as I am concerned we have an assertion that no SLAAC is >>a >> >> >> problem and existance proof that it is not. Beside CGA and >>requiring >> >> >> that hosts run DHCPv6 if they want an IPv6 GUA, what can I not >> >>support >> >> >> on these /112 subnets? >> >> >> >> >> >> Curtis >> >> >> >> >> >> >> >> >>> On 9/23/12 4:09 PM, "Curtis Villamizar" wrote: >> >> >>> >> >> >>>> In message <505E83F6.3030900@joelhalpern.com> >> >> >>>> "Joel M. Halpern" writes: >> >> >>>> >> >> >>>>> Since you invited flames... >> >> >>>>> >> >> >>>>> The argument on /64 as the longest prefix is not that it is >> >>magically >> >> >>>>> unnatural. >> >> >>>>> Rather, it is that there are a number of current and evolving >> >> >>> protocols >> >> >>>>> that depend upon that /64. The obvious example is that SLAAC >>does >> >> >>> not >> >> >>>>> work if subnets are longer than /64. >> >> >>>>> >> >> >>>>> The rules in this regard are written into approved RFCs. If >> >>homenet >> >> >>>>> wants to change that, it really needs to go to 6man with a >>strong >> >> >>> case. >> >> >>>>> (for point-to-point inter-router links this was recently >> >>relaxed. >> >> >>>>> >> >> >>>>> At the same time, andy operator who insists on giving homes a >>/64 >> >>is >> >> >>>>> being inappropriately restrictive. Homenet should say that, >> >>rather >> >> >>>>> than >> >> >>>>> trying to change the IPv6 architecture. >> >> >>>>> >> >> >>>>> Yours, >> >> >>>>> Joel >> >> >>>> Joel, >> >> >>>> >> >> >>>> I don't consider your email a flame at all. Thanks for >>responding. >> >> >>>> >> >> >>>> SLAAC (which I am not at a fan of) won't work but DHCPv6 will so >> >>IMHO >> >> >>>> no loss. CGA also won't work but then again I've also never >>been a >> >> >>>> fan of security half measures. Yes anti-spoofing without prior >> >> >>>> exchange of a key is nice, but no reasonable authorization >>could be >> >> >>>> based on CGA without also exchanging some sort of key or cert >>and >> >>at >> >> >>>> that point the CGA as a public key is redundant. >> >> >>>> >> >> >>>> If SLAAC and CGA are the only things that break *and* providers >>do >> >> >>>> hand out prefixes that are too small, then /64 prefixes will >>have >> >>to >> >> >>>> be subdivided. >> >> >>>> >> >> >>>> So a question for you is what else if anything will break? >> >> >>>> >> >> >>>> I also understand that you are suggesting that this be taken to >> >>6man. >> >> >>>> That is a good suggestion. >> >> >>>> >> >> >>>> Curtis >> >> >>>> >> >> >>>> >> >> >>>>> On 9/22/2012 11:30 PM, Curtis Villamizar wrote: >> >> >>>>>> 12. This is sure to be controversial. I pointed out that >> >>using >> >> >>>>>> subnets longer than /64 is OK as long as they are not >> >>leaked >> >> >>>>>> into global routing. Please read the text and changes >> >> >>> before >> >> >>>>>> exploding on this topic. It may be necessary to >>subnet a >> >> >>> /64 >> >> >>>>> if >> >> >>>>>> that is all a provider will give you and you need >>subnets. >> >> >>> It >> >> >>>>>> does work and it is no more unnatural than subnetting a >> >> >>> class-A >> >> >>>>>> network would be in 1990. It means using DHCPv6 and >>not >> >> >>> using >> >> >>>>>> RA prefixes for GUA (otherwise SLAAC implementations >>would >> >> >>>>>> likely try to use the whole bottom 64). >> >_______________________________________________ >> >homenet mailing list >> >homenet@ietf.org >> >https://www.ietf.org/mailman/listinfo/homenet >> >> From curtis@occnc.com Mon Sep 24 21:45: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 EC8CB21F8926 for ; Mon, 24 Sep 2012 21:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.118, 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 VYhWMNVOn4bw for ; Mon, 24 Sep 2012 21:45:20 -0700 (PDT) Received: from gateway1.orleans.occnc.com (gateway1.orleans.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id DB25D21F84E7 for ; Mon, 24 Sep 2012 21:45:19 -0700 (PDT) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id q8P4j5hD067401; Tue, 25 Sep 2012 00:45:05 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201209250445.q8P4j5hD067401@gateway1.orleans.occnc.com> To: Don Sturek From: Curtis Villamizar In-reply-to: Your message of "Mon, 24 Sep 2012 19:42:00 PDT." Date: Tue, 25 Sep 2012 00:45:05 -0400 Cc: homenet@ietf.org, "Joel M. Halpern" , Jim Gettys , curtis@occnc.com Subject: Re: [homenet] draft-ietf-homenet-arch-04 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, 25 Sep 2012 04:45:24 -0000 In message Don Sturek writes: > Hi Curtis, > > I think the difficulty is each device cannot "use the MAC to create a ULA > address". Some authoritative device in the network (eg, the AP) must > create the ULA prefix. If a ULA prefix is not present because the AP is a > legacy device not capable of providing a ULA prefix, the STA devices must > use link locals only. > > Don Don, You are right about there being nothing to generate the ULA prefix in your example. My mistake. But it doesn't change anything. If the AP is a dumb bridge and there is no router of any kind, then link local addresses are perfectly fine. There is only one subnet in that example, and ULA is not needed. That was the example you gave. Your example had no router just an old AP that acted as a bridge, therefore nothing to generate any sort of RA. If there is a router and no GUA prefix (which is not your example, but a useful example), then ULA can be used. The only RA that is seen is the RA providing a ULA prefix which the router can generate. I did say that the possibility of having to subdivide a /64 only exists for GUA. If a router exists which gets a GUA from a provider, and there are more subnets than the prefix length can support the two options are the ones listed below. (Search for --or--). Curtis > On 9/24/12 6:52 PM, "Curtis Villamizar" wrote: > > > > >In message > >Don Sturek writes: > > > >> Hi Curtis, > >> > >> I would expect most Wi-Fi AP manufacturers to support the same address > >> assignment they do today (ie, manual assignment and DHCP). I would > >> also expect as more IPv6 deployments happen that SLAAC will also be > >> supported (and, yes, even for GUA). > >> > >> For the types of devices which will be added to Wi-Fi networks in the > >> future (eg, headless devices like appliances, thermostats, etc.) that > >> the preferred address assignment will be SLAAC and DHCPv6 (and, yes, I > >> purposely did not remove SLAAC.....) > >> > >> Don > > > > > >Don, > > > >We seem to be talking past each other so let me again try to be clear. > > > >What every host does is: > > > > if it has no MAC: > > pick a random link local (not ULA) address > > else > > use the MAC to create a ULA address > > run DAD to make sure no one else has same address > > > > send a RS > > > > if it gets RA > > use the RA prefix for SLAAC > > else > > time out and don't bother with SLAAC > > > >then hopefully the host also does the following: > > > > send DHCPv6 client request > > > > if response > > it has yet another address to pick from if it got one using SLAAC > > else > > time out and get nothing from DHCPv6 > > > >Note: new extensions to DHCPv6 allow the host to tell DHCPv6 server > >the address that it already has (from SLAAC). > > > >If as in the case of your Wi-Fi with a bridging AP example, there is > >no router to give it an DHCPv6 the link local or ULA addresses are > >still there and still usable. There is also no router to give it an > >RA response so it has no SLAAC assigned address and no DHCPv6 assigned > >address. > > > >That is the end of your example. > > > >If there is a router then there is something that can hand out a RA or > >DHCPv6 response. > > > >In the case were there exists multiple subnets and the CER has been > >granted a /64 (or too few /64s to handle the number of subnets), then: > > > > it can use RA with /64 on some subnets and give them GUA addresses > > and some subnets have no access outside the homenet > > > > --or-- > > > > it can not use RA (and therefore prevent SLAAC from being used) and > > hand out DHCPv6 addresses and make use of prefixes longer than /64. > > This prevents the use of CGA but get connectivity to the entire > > homenet. > > > >If every consumer oriented provider is willing to allocate prefixes > >shorter than /64 on request to home users, then the above situation > >never occurs. If it does, my argument is that the second option above > >is better than the first. > > > >Curtis > > > > > >> On 9/24/12 5:11 PM, "Curtis Villamizar" wrote: > >> > >> > > >> >In message <5060BDC7.6020403@freedesktop.org> > >> >Jim Gettys writes: > >> > > >> >> On 09/24/2012 03:17 PM, Don Sturek wrote: > >> >> > Hi Curtis, > >> >> > > >> >> > Here is the use case: > >> >> > 1) Customer has a legacy AP in their house > >> >> > 2) Customer brings home new devices supporting IPv6 (which are > >> >>designed > >> >> > to communicate only with other IPv6 based devices in the home) > >> >> > 3) The only way these new devices can communicate is through > >>address > >> >> > assignment using SLAAC and then some discovery method the two new > >> >>devices > >> >> > support (without support from the AP). Here these devices are > >> >>assuming > >> >> > bridging through the AP...... > >> >> > >> >> And since current legacy AP's all bridge, we win (even though we > >>need to > >> >> route in the future). > >> > > >> >Jim, > >> > > >> >The point was how do you get local IPv6 within the home with the > >> >legacy AP that does only IPv4 and just does bridging of IPv6. First > >> >of all you have no subnets. There is no CER to do DHCPv6. > >> > > >> >In this case you use link local or if everything has a MAC you can use > >> >ULA based on the MAC addressses. > >> > > >> >> > Placing a requirement that every customer who buys a new IPv6 > >>device, > >> >> > intended to communicate only with other IPv6 devices in the home, > >>will > >> >> > require a forklift upgrade of a deployed network in order to work > >> >>will not > >> >> > be popular. > >> >> > >> >> Good point. > >> > > >> >But invalid. The use case Don gave would still work fine. Only GUA > >> >addresses are affected. > >> > > >> >> I loathe DHCP (of any sort) *for basic address assignment, anyway* in > >> >> the home environment. > >> >> > >> >> The loathing comes from the exquisite pain of suffering with a flaky > >> >> home network for several months, before realising I had a rogue DHCP > >> >> server somewhere on my network (from wireshark). I then had to take > >>the > >> >> mac address, figure out who may have manufactured some device from > >>that > >> >> information, and finally figured out the little VOIP ATA adaptor I > >>had > >> >> been given liked to do DHCP. > >> > > >> >It did DHCP on the *WAN side*? You didn't put the rest of your > >> >network behind the VOIP box on the LAN side I hope. > >> > > >> >> This was by far the hardest debugging I've had to do in my home > >>network > >> >> in normal operation. > >> >> > >> >> This is well beyond normal home debugging capability of consumers. > >> >> - Jim > >> > > >> >We all have plenty of crappy IPv4 product horror stories. My VOIP > >> >phone locked up now and then and I figured out that if the call lasted > >> >longer than the DHCPv4 lease, then it lost the least because it didn't > >> >try to renew it. Not only did the call drop, but the device locked > >> >up. The first solution was to reboot it now and then. The answer was > >> >to configure a fixed address. I was lucky to figure it out before my > >> >wife threw the phone through a window. For all I know a later > >> >firmware upgrade might have fixed it. VOIP might be more popular if > >> >VOIP phones under $600 worked reasonably well. > >> > > >> >Both nice stories, but both are DHCPv4 related and have nothing at all > >> >to do with SLAAC. > >> > > >> >Curtis > >> > > >> >> > Don > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > On 9/24/12 11:49 AM, "Curtis Villamizar" wrote: > >> >> > > >> >> >> In message > >> >> >> Don Sturek writes: > >> >> >> > >> >> >>> Hi Curtis, > >> >> >>> > >> >> >>> SLAAC not working is a major problem. > >> >> >>> > >> >> >>> Don > >> >> >> > >> >> >> Don, > >> >> >> > >> >> >> Why? This is an assertion without basis as far as I am concerned. > >> >> >> Except CGA there is nothing that breaks without SLAAC. Joel > >>brought > >> >> >> up ILNP in private email, but I beleive ILNP can also work as the > >> >> >> constraints in ILNP are in the ILNP identifier which is not the > >>same > >> >> >> as the interface address in ILNP for which there is no constraint. > >> >> >> > >> >> >> I have subnets running fine using a few /112 allocated from > >>within a > >> >> >> /64 with fixed addresses on rack mount hosts and desktops and > >>DHCPv6 > >> >> >> for dynamic allocations for laptops. It works fine. Link local > >> >> >> addresses are all that is needed to get DHCPv6 to work. No host > >>ever > >> >> >> receives a RA since my routers won't give them one, so no host > >>ever > >> >> >> tries to generate an address using SLAAC. The only constraint is > >> >>that > >> >> >> any host connecting to my Ethernet or wireless must run a DHCP > >>client > >> >> >> and if they want an IPv6 GUA must run a DHCPv6 client. DHCPv4 and > >> >> >> DHCPv6 servers are available in every subnet except one GbE > >>subnet in > >> >> >> the rack and to a few hosts in my home office. > >> >> >> > >> >> >> So as far as I am concerned we have an assertion that no SLAAC is > >>a > >> >> >> problem and existance proof that it is not. Beside CGA and > >>requiring > >> >> >> that hosts run DHCPv6 if they want an IPv6 GUA, what can I not > >> >>support > >> >> >> on these /112 subnets? > >> >> >> > >> >> >> Curtis > >> >> >> > >> >> >> > >> >> >>> On 9/23/12 4:09 PM, "Curtis Villamizar" wrote: > >> >> >>> > >> >> >>>> In message <505E83F6.3030900@joelhalpern.com> > >> >> >>>> "Joel M. Halpern" writes: > >> >> >>>> > >> >> >>>>> Since you invited flames... > >> >> >>>>> > >> >> >>>>> The argument on /64 as the longest prefix is not that it is > >> >>magically > >> >> >>>>> unnatural. > >> >> >>>>> Rather, it is that there are a number of current and evolving > >> >> >>> protocols > >> >> >>>>> that depend upon that /64. The obvious example is that SLAAC > >>does > >> >> >>> not > >> >> >>>>> work if subnets are longer than /64. > >> >> >>>>> > >> >> >>>>> The rules in this regard are written into approved RFCs. If > >> >>homenet > >> >> >>>>> wants to change that, it really needs to go to 6man with a > >>strong > >> >> >>> case. > >> >> >>>>> (for point-to-point inter-router links this was recently > >> >>relaxed. > >> >> >>>>> > >> >> >>>>> At the same time, andy operator who insists on giving homes a > >>/64 > >> >>is > >> >> >>>>> being inappropriately restrictive. Homenet should say that, > >> >>rather > >> >> >>>>> than > >> >> >>>>> trying to change the IPv6 architecture. > >> >> >>>>> > >> >> >>>>> Yours, > >> >> >>>>> Joel > >> >> >>>> Joel, > >> >> >>>> > >> >> >>>> I don't consider your email a flame at all. Thanks for > >>responding. > >> >> >>>> > >> >> >>>> SLAAC (which I am not at a fan of) won't work but DHCPv6 will so > >> >>IMHO > >> >> >>>> no loss. CGA also won't work but then again I've also never > >>been a > >> >> >>>> fan of security half measures. Yes anti-spoofing without prior > >> >> >>>> exchange of a key is nice, but no reasonable authorization > >>could be > >> >> >>>> based on CGA without also exchanging some sort of key or cert > >>and > >> >>at > >> >> >>>> that point the CGA as a public key is redundant. > >> >> >>>> > >> >> >>>> If SLAAC and CGA are the only things that break *and* providers > >>do > >> >> >>>> hand out prefixes that are too small, then /64 prefixes will > >>have > >> >>to > >> >> >>>> be subdivided. > >> >> >>>> > >> >> >>>> So a question for you is what else if anything will break? > >> >> >>>> > >> >> >>>> I also understand that you are suggesting that this be taken to > >> >>6man. > >> >> >>>> That is a good suggestion. > >> >> >>>> > >> >> >>>> Curtis > >> >> >>>> > >> >> >>>> > >> >> >>>>> On 9/22/2012 11:30 PM, Curtis Villamizar wrote: > >> >> >>>>>> 12. This is sure to be controversial. I pointed out that > >> >>using > >> >> >>>>>> subnets longer than /64 is OK as long as they are not > >> >>leaked > >> >> >>>>>> into global routing. Please read the text and changes > >> >> >>> before > >> >> >>>>>> exploding on this topic. It may be necessary to > >>subnet a > >> >> >>> /64 > >> >> >>>>> if > >> >> >>>>>> that is all a provider will give you and you need > >>subnets. > >> >> >>> It > >> >> >>>>>> does work and it is no more unnatural than subnetting a > >> >> >>> class-A > >> >> >>>>>> network would be in 1990. It means using DHCPv6 and > >>not > >> >> >>> using > >> >> >>>>>> RA prefixes for GUA (otherwise SLAAC implementations > >>would > >> >> >>>>>> likely try to use the whole bottom 64). > >> >_______________________________________________ > >> >homenet mailing list > >> >homenet@ietf.org > >> >https://www.ietf.org/mailman/listinfo/homenet From robert.cragie@gridmerge.com Tue Sep 25 01:56: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 958CD21F88F8 for ; Tue, 25 Sep 2012 01:56:16 -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 ZzgBEYDdn384 for ; Tue, 25 Sep 2012 01:56:15 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by ietfa.amsl.com (Postfix) with ESMTP id BE8B121F894F for ; Tue, 25 Sep 2012 01:56:14 -0700 (PDT) Received: from client-86-31-182-56.oxfd.adsl.virginmedia.com ([86.31.182.56] helo=[192.168.0.2]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) id 1TGQw8-0007VZ-1e for homenet@ietf.org; Tue, 25 Sep 2012 09:56:12 +0100 Message-ID: <506171E1.1080802@gridmerge.com> Date: Tue, 25 Sep 2012 09:57:05 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: homenet@ietf.org References: <201209250445.q8P4j5hD067401@gateway1.orleans.occnc.com> In-Reply-To: <201209250445.q8P4j5hD067401@gateway1.orleans.occnc.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040903020706030109060200" X-Authenticated-As: robert.cragie@gridmerge.com Subject: Re: [homenet] draft-ietf-homenet-arch-04 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 08:56:16 -0000 This is a cryptographically signed message in MIME format. --------------ms040903020706030109060200 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable So let's tweak Curtis' sequence slightly: What every host does is: if it has no MAC: pick a random link local address else use the MAC to create a link local address run DAD to make sure no one else has same address send a RS if it gets RA use the RA prefix for SLAAC else time out and don't bother with SLAAC; can only use link local address= then hopefully the host also does the following: send DHCPv6 client request if response it has yet another address to pick from if it got one using SLAAC else time out and get nothing from DHCPv6 This should work fine for legacy APs where everything is bridged=20 underneath it. Where it gets interesting is in the case of cascaded=20 subnets behind a router connected to an ISP, where one or more of those=20 subnets may be a mesh network comprised of mesh routers and hosts. I am=20 not quite sure how ULAs and DHCPv6 would work in this case as there are=20 limitations as far as I can see (although I accept I probably have a bit = more reading to do on the subject). Robert On 25/09/2012 5:45 AM, Curtis Villamizar wrote: > In message > Don Sturek writes: > =20 >> Hi Curtis, >> =20 >> I think the difficulty is each device cannot "use the MAC to create a = ULA >> address". Some authoritative device in the network (eg, the AP) must >> create the ULA prefix. If a ULA prefix is not present because the AP = is a >> legacy device not capable of providing a ULA prefix, the STA devices m= ust >> use link locals only. >> =20 >> Don > > Don, > > You are right about there being nothing to generate the ULA prefix in > your example. My mistake. > > But it doesn't change anything. If the AP is a dumb bridge and there > is no router of any kind, then link local addresses are perfectly > fine. There is only one subnet in that example, and ULA is not > needed. That was the example you gave. > > Your example had no router just an old AP that acted as a bridge, > therefore nothing to generate any sort of RA. If there is a router > and no GUA prefix (which is not your example, but a useful example), > then ULA can be used. The only RA that is seen is the RA providing a > ULA prefix which the router can generate. > > I did say that the possibility of having to subdivide a /64 only > exists for GUA. If a router exists which gets a GUA from a provider, > and there are more subnets than the prefix length can support the two > options are the ones listed below. (Search for --or--). > > Curtis > > >> On 9/24/12 6:52 PM, "Curtis Villamizar" wrote: >> =20 >>> In message >>> Don Sturek writes: >>> >>>> Hi Curtis, >>>> =20 >>>> I would expect most Wi-Fi AP manufacturers to support the same addre= ss >>>> assignment they do today (ie, manual assignment and DHCP). I would >>>> also expect as more IPv6 deployments happen that SLAAC will also be >>>> supported (and, yes, even for GUA). >>>> =20 >>>> For the types of devices which will be added to Wi-Fi networks in th= e >>>> future (eg, headless devices like appliances, thermostats, etc.) tha= t >>>> the preferred address assignment will be SLAAC and DHCPv6 (and, yes,= I >>>> purposely did not remove SLAAC.....) >>>> =20 >>>> Don >>> >>> Don, >>> >>> We seem to be talking past each other so let me again try to be clear= =2E >>> >>> What every host does is: >>> >>> if it has no MAC: >>> pick a random link local (not ULA) address >>> else >>> use the MAC to create a ULA address >>> run DAD to make sure no one else has same address >>> >>> send a RS >>> >>> if it gets RA >>> use the RA prefix for SLAAC >>> else >>> time out and don't bother with SLAAC >>> >>> then hopefully the host also does the following: >>> >>> send DHCPv6 client request >>> >>> if response >>> it has yet another address to pick from if it got one using SLAAC= >>> else >>> time out and get nothing from DHCPv6 >>> >>> Note: new extensions to DHCPv6 allow the host to tell DHCPv6 server >>> the address that it already has (from SLAAC). >>> >>> If as in the case of your Wi-Fi with a bridging AP example, there is >>> no router to give it an DHCPv6 the link local or ULA addresses are >>> still there and still usable. There is also no router to give it an >>> RA response so it has no SLAAC assigned address and no DHCPv6 assigne= d >>> address. >>> >>> That is the end of your example. >>> >>> If there is a router then there is something that can hand out a RA o= r >>> DHCPv6 response. >>> >>> In the case were there exists multiple subnets and the CER has been >>> granted a /64 (or too few /64s to handle the number of subnets), then= : >>> >>> it can use RA with /64 on some subnets and give them GUA addresses >>> and some subnets have no access outside the homenet >>> >>> --or-- >>> >>> it can not use RA (and therefore prevent SLAAC from being used) and= >>> hand out DHCPv6 addresses and make use of prefixes longer than /64.= >>> This prevents the use of CGA but get connectivity to the entire >>> homenet. >>> >>> If every consumer oriented provider is willing to allocate prefixes >>> shorter than /64 on request to home users, then the above situation >>> never occurs. If it does, my argument is that the second option abov= e >>> is better than the first. >>> >>> Curtis >>> >>> >>>> On 9/24/12 5:11 PM, "Curtis Villamizar" wrote: >>>> =20 >>>>> In message <5060BDC7.6020403@freedesktop.org> >>>>> Jim Gettys writes: >>>>> >>>>>> On 09/24/2012 03:17 PM, Don Sturek wrote: >>>>>>> Hi Curtis, >>>>>>> >>>>>>> Here is the use case: >>>>>>> 1) Customer has a legacy AP in their house >>>>>>> 2) Customer brings home new devices supporting IPv6 (which are >>>>>> designed >>>>>>> to communicate only with other IPv6 based devices in the home) >>>>>>> 3) The only way these new devices can communicate is through >>>> address >>>>>>> assignment using SLAAC and then some discovery method the two new= >>>>>> devices >>>>>>> support (without support from the AP). Here these devices are >>>>>> assuming >>>>>>> bridging through the AP...... >>>>>> =20 >>>>>> And since current legacy AP's all bridge, we win (even though we >>>> need to >>>>>> route in the future). >>>>> Jim, >>>>> >>>>> The point was how do you get local IPv6 within the home with the >>>>> legacy AP that does only IPv4 and just does bridging of IPv6. Firs= t >>>>> of all you have no subnets. There is no CER to do DHCPv6. >>>>> >>>>> In this case you use link local or if everything has a MAC you can = use >>>>> ULA based on the MAC addressses. >>>>> >>>>>>> Placing a requirement that every customer who buys a new IPv6 >>>> device, >>>>>>> intended to communicate only with other IPv6 devices in the home,= >>>> will >>>>>>> require a forklift upgrade of a deployed network in order to work= >>>>>> will not >>>>>>> be popular. >>>>>> =20 >>>>>> Good point. >>>>> But invalid. The use case Don gave would still work fine. Only GU= A >>>>> addresses are affected. >>>>> >>>>>> I loathe DHCP (of any sort) *for basic address assignment, anyway*= in >>>>>> the home environment. >>>>>> =20 >>>>>> The loathing comes from the exquisite pain of suffering with a fla= ky >>>>>> home network for several months, before realising I had a rogue D= HCP >>>>>> server somewhere on my network (from wireshark). I then had to ta= ke >>>> the >>>>>> mac address, figure out who may have manufactured some device from= >>>> that >>>>>> information, and finally figured out the little VOIP ATA adaptor I= >>>> had >>>>>> been given liked to do DHCP. >>>>> It did DHCP on the *WAN side*? You didn't put the rest of your >>>>> network behind the VOIP box on the LAN side I hope. >>>>> >>>>>> This was by far the hardest debugging I've had to do in my home >>>> network >>>>>> in normal operation. >>>>>> =20 >>>>>> This is well beyond normal home debugging capability of consumers.= >>>>>> - Jim >>>>> We all have plenty of crappy IPv4 product horror stories. My VOIP >>>>> phone locked up now and then and I figured out that if the call las= ted >>>>> longer than the DHCPv4 lease, then it lost the least because it did= n't >>>>> try to renew it. Not only did the call drop, but the device locked= >>>>> up. The first solution was to reboot it now and then. The answer = was >>>>> to configure a fixed address. I was lucky to figure it out before = my >>>>> wife threw the phone through a window. For all I know a later >>>>> firmware upgrade might have fixed it. VOIP might be more popular i= f >>>>> VOIP phones under $600 worked reasonably well. >>>>> >>>>> Both nice stories, but both are DHCPv4 related and have nothing at = all >>>>> to do with SLAAC. >>>>> >>>>> Curtis >>>>> >>>>>>> Don >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 9/24/12 11:49 AM, "Curtis Villamizar" wrote= : >>>>>>> >>>>>>>> In message >>>>>>>> Don Sturek writes: >>>>>>>> >>>>>>>>> Hi Curtis, >>>>>>>>> =20 >>>>>>>>> SLAAC not working is a major problem. >>>>>>>>> =20 >>>>>>>>> Don >>>>>>>> Don, >>>>>>>> >>>>>>>> Why? This is an assertion without basis as far as I am concerne= d. >>>>>>>> Except CGA there is nothing that breaks without SLAAC. Joel >>>> brought >>>>>>>> up ILNP in private email, but I beleive ILNP can also work as th= e >>>>>>>> constraints in ILNP are in the ILNP identifier which is not the >>>> same >>>>>>>> as the interface address in ILNP for which there is no constrain= t. >>>>>>>> >>>>>>>> I have subnets running fine using a few /112 allocated from >>>> within a >>>>>>>> /64 with fixed addresses on rack mount hosts and desktops and >>>> DHCPv6 >>>>>>>> for dynamic allocations for laptops. It works fine. Link local= >>>>>>>> addresses are all that is needed to get DHCPv6 to work. No host= >>>> ever >>>>>>>> receives a RA since my routers won't give them one, so no host >>>> ever >>>>>>>> tries to generate an address using SLAAC. The only constraint i= s >>>>>> that >>>>>>>> any host connecting to my Ethernet or wireless must run a DHCP >>>> client >>>>>>>> and if they want an IPv6 GUA must run a DHCPv6 client. DHCPv4 a= nd >>>>>>>> DHCPv6 servers are available in every subnet except one GbE >>>> subnet in >>>>>>>> the rack and to a few hosts in my home office. >>>>>>>> >>>>>>>> So as far as I am concerned we have an assertion that no SLAAC i= s >>>> a >>>>>>>> problem and existance proof that it is not. Beside CGA and >>>> requiring >>>>>>>> that hosts run DHCPv6 if they want an IPv6 GUA, what can I not >>>>>> support >>>>>>>> on these /112 subnets? >>>>>>>> >>>>>>>> Curtis >>>>>>>> >>>>>>>> >>>>>>>>> On 9/23/12 4:09 PM, "Curtis Villamizar" wrot= e: >>>>>>>>> =20 >>>>>>>>>> In message <505E83F6.3030900@joelhalpern.com> >>>>>>>>>> "Joel M. Halpern" writes: >>>>>>>>>> >>>>>>>>>>> Since you invited flames... >>>>>>>>>>> =20 >>>>>>>>>>> The argument on /64 as the longest prefix is not that it is >>>>>> magically >>>>>>>>>>> unnatural. >>>>>>>>>>> Rather, it is that there are a number of current and evolving= >>>>>>>>> protocols >>>>>>>>>>> that depend upon that /64. The obvious example is that SLAAC= >>>> does >>>>>>>>> not >>>>>>>>>>> work if subnets are longer than /64. >>>>>>>>>>> =20 >>>>>>>>>>> The rules in this regard are written into approved RFCs. If >>>>>> homenet >>>>>>>>>>> wants to change that, it really needs to go to 6man with a >>>> strong >>>>>>>>> case. >>>>>>>>>>> (for point-to-point inter-router links this was recently >>>>>> relaxed. >>>>>>>>>>> =20 >>>>>>>>>>> At the same time, andy operator who insists on giving homes a= >>>> /64 >>>>>> is >>>>>>>>>>> being inappropriately restrictive. Homenet should say that, >>>>>> rather >>>>>>>>>>> than >>>>>>>>>>> trying to change the IPv6 architecture. >>>>>>>>>>> =20 >>>>>>>>>>> Yours, >>>>>>>>>>> Joel >>>>>>>>>> Joel, >>>>>>>>>> >>>>>>>>>> I don't consider your email a flame at all. Thanks for >>>> responding. >>>>>>>>>> SLAAC (which I am not at a fan of) won't work but DHCPv6 will = so >>>>>> IMHO >>>>>>>>>> no loss. CGA also won't work but then again I've also never >>>> been a >>>>>>>>>> fan of security half measures. Yes anti-spoofing without prio= r >>>>>>>>>> exchange of a key is nice, but no reasonable authorization >>>> could be >>>>>>>>>> based on CGA without also exchanging some sort of key or cert >>>> and >>>>>> at >>>>>>>>>> that point the CGA as a public key is redundant. >>>>>>>>>> >>>>>>>>>> If SLAAC and CGA are the only things that break *and* provider= s >>>> do >>>>>>>>>> hand out prefixes that are too small, then /64 prefixes will >>>> have >>>>>> to >>>>>>>>>> be subdivided. >>>>>>>>>> >>>>>>>>>> So a question for you is what else if anything will break? >>>>>>>>>> >>>>>>>>>> I also understand that you are suggesting that this be taken t= o >>>>>> 6man. >>>>>>>>>> That is a good suggestion. >>>>>>>>>> >>>>>>>>>> Curtis >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On 9/22/2012 11:30 PM, Curtis Villamizar wrote: >>>>>>>>>>>> 12. This is sure to be controversial. I pointed out tha= t >>>>>> using >>>>>>>>>>>> subnets longer than /64 is OK as long as they are no= t >>>>>> leaked >>>>>>>>>>>> into global routing. Please read the text and chang= es >>>>>>>>> before >>>>>>>>>>>> exploding on this topic. It may be necessary to >>>> subnet a >>>>>>>>> /64 >>>>>>>>>>> if >>>>>>>>>>>> that is all a provider will give you and you need >>>> subnets. >>>>>>>>> It >>>>>>>>>>>> does work and it is no more unnatural than subnettin= g a >>>>>>>>> class-A >>>>>>>>>>>> network would be in 1990. It means using DHCPv6 and= >>>> not >>>>>>>>> using >>>>>>>>>>>> RA prefixes for GUA (otherwise SLAAC implementations= >>>> would >>>>>>>>>>>> likely try to use the whole bottom 64). >>>>> _______________________________________________ >>>>> homenet mailing list >>>>> homenet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/homenet > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > --------------ms040903020706030109060200 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUDCC BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq 1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg 7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1 c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo 2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q peeU0rD+83X5f27nMIIGLjCCBRagAwIBAgIQXDFQ28QtqMuYch5f2nTvZjANBgkqhkiG9w0B AQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMTA5 MDIwMDAwMDBaFw0xNDA5MDEyMzU5NTlaMIIBNzELMAkGA1UEBhMCR0IxEDAOBgNVBBETB1dG NCA0V0ExFzAVBgNVBAgTDldlc3QgWW9ya3NoaXJlMRIwEAYDVQQHEwlXYWtlZmllbGQxFDAS BgNVBAkTC0dyYW5nZSBNb29yMR8wHQYDVQQJExY4OSBHcmVlbmZpZWxkIENyZXNjZW50MRcw FQYDVQQKEw5HcmlkbWVyZ2UgTHRkLjE0MDIGA1UECxMrSXNzdWVkIHRocm91Z2ggR3JpZG1l cmdlIEx0ZC4gRS1QS0kgTWFuYWdlcjEfMB0GA1UECxMWQ29ycG9yYXRlIFNlY3VyZSBFbWFp bDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdp ZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArcThqvLe WU1Q1ZJmnb+2UQSwOQKWok3A1Mwk582AdvwaAQyBFliPyJ0kXJqtwNBoZvk+3WJr0QA5ZRr+ J0x3sXVpcxadojP2HNzy1gsgDtIGG8ltoU4vmX1A8BTlOIUT+Pg8p/bSruxV0vz0CR8ho2hs R0Zi5vU+rQKNmbgufbkWhlQnMEYjknemscLQfw1YZz90ta67doNDujFy6+X6I06HpjudgMYx 8bdsNS5xVFFwuBA1eqNQra+xLzhCOeX9PPB/zK68qdNhrni3WPYG9EhSt4Dzk+xIz9hj7wrU ZIVXDTPsY8qbUSBVpwmzI5lCHPgzurH1OK7WwgpDSsl5pwIDAQABo4IB1TCCAdEwHwYDVR0j BBgwFoAUehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFBCOXNH+lDm8U9gy3b3bRvrx vKgrMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEDBTArMCkGCCsGAQUFBwIBFh1o dHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBIhkZodHRwOi8v Y3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVt YWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6Ly9jcnQuY29t b2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5j cnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRty b2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBAD6b/O0LkPav kR4Znoqxg0Ad7M3duDm4uzfrlX4ecgq56Ccdwd+3Tayz7Ewej30woVMmTKkA/NKRaCd0wVM9 8seF/oZjXKO7o1SH27igRnGSWjCoWXsdwJGfZbYnvcIIhhsxJoCPNbeSR7C0PAFDKsP3xrJy MHMljIJsoRbZu/fnYNyFWh9OXf7fYJOGmKDKAhSabUGfhY7umvU9d/YTqo02Q6YzC7d4zPNG 1a75AuHSEchf6GdKqycG38I5y9jlDaYfXspoS3PlTNCIeZONbOSMZgftnNEVKq+SWytFqyG/ 8+dwpm/a12KMex5J8iHwaUKj++2O2rAFNjDDqXpeEYoxggQZMIIEFQIBATCBqDCBkzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQXDFQ28QtqMuYch5f2nTvZjAJ BgUrDgMCGgUAoIICRTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjA5MjUwODU3MDVaMCMGCSqGSIb3DQEJBDEWBBRaue0jH5hRVBKcHrI3pLnutkZo4TBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEFwxUNvELajLmHIeX9p072YwgbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9m MA0GCSqGSIb3DQEBAQUABIIBAE0rXOwM8dm4SKs8t6KLhivzvwfoPRSWT1YcNG4bAvsod+U/ Y9wBQduZhLvCPU6+6y7jdf25IaNuoUviQ70XGp0NU+p5FxgHkp0s8bAZLUqxIll635eobfIg I3qsMnO0dlNtTbnd0ES3Y/0Dcgx1f/84Hm9dtY1DMOiGM9Y60aYeMZ6tztAQkduzF8E4W/tw Yzkh/c+hTMTUIlOk5zWk1LK/GhSU+vZebUqL2T5GRZhwof6fwGS1hprPqMTx+BrxocvTG1y/ zoOZYsnadHZEfPqZx3ZPhpxK8N1b990KZVtu7bqnIjw9DN+yw0K1h+APCUlZBPA2aAarOZbI XLxQBv0AAAAAAAA= --------------ms040903020706030109060200-- From brian.e.carpenter@gmail.com Tue Sep 25 06: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 CAC8721F868A for ; Tue, 25 Sep 2012 06:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.559 X-Spam-Level: X-Spam-Status: No, score=-103.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 z7AkXC6DS-kr for ; Tue, 25 Sep 2012 06:35:28 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id DB38A21F865D for ; Tue, 25 Sep 2012 06:35:27 -0700 (PDT) Received: by iec9 with SMTP id 9so15335489iec.31 for ; Tue, 25 Sep 2012 06:35:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=vjN8+qbeY1ZeBWMnPgZJzGDVYYoanJpZhj643vYXxlA=; b=eeafQt8cOzebnzB4tBururYXDipqUJnKXXsqpkNTlMh9M8QQE3B/XdaRmbEAOsuWaA Z3/DGibmOfrUizuNhEsK6OX6urYMH8Pj8TZFHoSfdmT7hfwBLACDAxkmKWfL31/54iIc 3Xy6hoXJDANqhbd43Bn+wcJOKFj3kbmGUtnBcCtD7dApPUffLes+LMuGCNnGnT1AyR2t snm+Q4pYLa2VosuzLqzskaN9C0SUggpSdLwntPZx8u78l1poL4xQdIhi2Dae6ZzyT9cd DpCun/aij7LfMy5YRTJGzOvvhmsyZD7WwPvwV0+SKtpz6Ew0YJo37SiotlPHccmg1XGG k27w== Received: by 10.50.158.193 with SMTP id ww1mr8107631igb.30.1348580127204; Tue, 25 Sep 2012 06:35:27 -0700 (PDT) Received: from [10.255.25.102] (50-76-68-140-static.hfc.comcastbusiness.net. [50.76.68.140]) by mx.google.com with ESMTPS id p8sm8036428igl.16.2012.09.25.06.35.26 (version=SSLv3 cipher=OTHER); Tue, 25 Sep 2012 06:35:26 -0700 (PDT) Message-ID: <5061B322.1080805@gmail.com> Date: Tue, 25 Sep 2012 14:35:30 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Don Sturek References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org, "Joel M. Halpern" , Jim Gettys , curtis@occnc.com Subject: Re: [homenet] draft-ietf-homenet-arch-04 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 13:35:32 -0000 On 25/09/2012 02:01, Don Sturek wrote: > Hi Curtis, > > I would expect most Wi-Fi AP manufacturers to support the same address > assignment they do today (ie, manual assignment and DHCP). I would also > expect as more IPv6 deployments happen that SLAAC will also be supported > (and, yes, even for GUA). It MUST be supported according to RFC 6204 and 6204bis (and of course by all hosts, according to RFC 6434). Brian > > For the types of devices which will be added to Wi-Fi networks in the > future (eg, headless devices like appliances, thermostats, etc.) that the > preferred address assignment will be SLAAC and DHCPv6 (and, yes, I > purposely did not remove SLAAC.....) > > Don > > > > On 9/24/12 5:11 PM, "Curtis Villamizar" wrote: > >> In message <5060BDC7.6020403@freedesktop.org> >> Jim Gettys writes: >> >>> On 09/24/2012 03:17 PM, Don Sturek wrote: >>>> Hi Curtis, >>>> >>>> Here is the use case: >>>> 1) Customer has a legacy AP in their house >>>> 2) Customer brings home new devices supporting IPv6 (which are >>> designed >>>> to communicate only with other IPv6 based devices in the home) >>>> 3) The only way these new devices can communicate is through address >>>> assignment using SLAAC and then some discovery method the two new >>> devices >>>> support (without support from the AP). Here these devices are >>> assuming >>>> bridging through the AP...... >>> >>> And since current legacy AP's all bridge, we win (even though we need to >>> route in the future). >> Jim, >> >> The point was how do you get local IPv6 within the home with the >> legacy AP that does only IPv4 and just does bridging of IPv6. First >> of all you have no subnets. There is no CER to do DHCPv6. >> >> In this case you use link local or if everything has a MAC you can use >> ULA based on the MAC addressses. >> >>>> Placing a requirement that every customer who buys a new IPv6 device, >>>> intended to communicate only with other IPv6 devices in the home, will >>>> require a forklift upgrade of a deployed network in order to work >>> will not >>>> be popular. >>> >>> Good point. >> But invalid. The use case Don gave would still work fine. Only GUA >> addresses are affected. >> >>> I loathe DHCP (of any sort) *for basic address assignment, anyway* in >>> the home environment. >>> >>> The loathing comes from the exquisite pain of suffering with a flaky >>> home network for several months, before realising I had a rogue DHCP >>> server somewhere on my network (from wireshark). I then had to take the >>> mac address, figure out who may have manufactured some device from that >>> information, and finally figured out the little VOIP ATA adaptor I had >>> been given liked to do DHCP. >> It did DHCP on the *WAN side*? You didn't put the rest of your >> network behind the VOIP box on the LAN side I hope. >> >>> This was by far the hardest debugging I've had to do in my home network >>> in normal operation. >>> >>> This is well beyond normal home debugging capability of consumers. >>> - Jim >> We all have plenty of crappy IPv4 product horror stories. My VOIP >> phone locked up now and then and I figured out that if the call lasted >> longer than the DHCPv4 lease, then it lost the least because it didn't >> try to renew it. Not only did the call drop, but the device locked >> up. The first solution was to reboot it now and then. The answer was >> to configure a fixed address. I was lucky to figure it out before my >> wife threw the phone through a window. For all I know a later >> firmware upgrade might have fixed it. VOIP might be more popular if >> VOIP phones under $600 worked reasonably well. >> >> Both nice stories, but both are DHCPv4 related and have nothing at all >> to do with SLAAC. >> >> Curtis >> >>>> Don >>>> >>>> >>>> >>>> >>>> On 9/24/12 11:49 AM, "Curtis Villamizar" wrote: >>>> >>>>> In message >>>>> Don Sturek writes: >>>>> >>>>>> Hi Curtis, >>>>>> >>>>>> SLAAC not working is a major problem. >>>>>> >>>>>> Don >>>>> Don, >>>>> >>>>> Why? This is an assertion without basis as far as I am concerned. >>>>> Except CGA there is nothing that breaks without SLAAC. Joel brought >>>>> up ILNP in private email, but I beleive ILNP can also work as the >>>>> constraints in ILNP are in the ILNP identifier which is not the same >>>>> as the interface address in ILNP for which there is no constraint. >>>>> >>>>> I have subnets running fine using a few /112 allocated from within a >>>>> /64 with fixed addresses on rack mount hosts and desktops and DHCPv6 >>>>> for dynamic allocations for laptops. It works fine. Link local >>>>> addresses are all that is needed to get DHCPv6 to work. No host ever >>>>> receives a RA since my routers won't give them one, so no host ever >>>>> tries to generate an address using SLAAC. The only constraint is >>> that >>>>> any host connecting to my Ethernet or wireless must run a DHCP client >>>>> and if they want an IPv6 GUA must run a DHCPv6 client. DHCPv4 and >>>>> DHCPv6 servers are available in every subnet except one GbE subnet in >>>>> the rack and to a few hosts in my home office. >>>>> >>>>> So as far as I am concerned we have an assertion that no SLAAC is a >>>>> problem and existance proof that it is not. Beside CGA and requiring >>>>> that hosts run DHCPv6 if they want an IPv6 GUA, what can I not >>> support >>>>> on these /112 subnets? >>>>> >>>>> Curtis >>>>> >>>>> >>>>>> On 9/23/12 4:09 PM, "Curtis Villamizar" wrote: >>>>>> >>>>>>> In message <505E83F6.3030900@joelhalpern.com> >>>>>>> "Joel M. Halpern" writes: >>>>>>> >>>>>>>> Since you invited flames... >>>>>>>> >>>>>>>> The argument on /64 as the longest prefix is not that it is >>> magically >>>>>>>> unnatural. >>>>>>>> Rather, it is that there are a number of current and evolving >>>>>> protocols >>>>>>>> that depend upon that /64. The obvious example is that SLAAC does >>>>>> not >>>>>>>> work if subnets are longer than /64. >>>>>>>> >>>>>>>> The rules in this regard are written into approved RFCs. If >>> homenet >>>>>>>> wants to change that, it really needs to go to 6man with a strong >>>>>> case. >>>>>>>> (for point-to-point inter-router links this was recently >>> relaxed. >>>>>>>> >>>>>>>> At the same time, andy operator who insists on giving homes a /64 >>> is >>>>>>>> being inappropriately restrictive. Homenet should say that, >>> rather >>>>>>>> than >>>>>>>> trying to change the IPv6 architecture. >>>>>>>> >>>>>>>> Yours, >>>>>>>> Joel >>>>>>> Joel, >>>>>>> >>>>>>> I don't consider your email a flame at all. Thanks for responding. >>>>>>> >>>>>>> SLAAC (which I am not at a fan of) won't work but DHCPv6 will so >>> IMHO >>>>>>> no loss. CGA also won't work but then again I've also never been a >>>>>>> fan of security half measures. Yes anti-spoofing without prior >>>>>>> exchange of a key is nice, but no reasonable authorization could be >>>>>>> based on CGA without also exchanging some sort of key or cert and >>> at >>>>>>> that point the CGA as a public key is redundant. >>>>>>> >>>>>>> If SLAAC and CGA are the only things that break *and* providers do >>>>>>> hand out prefixes that are too small, then /64 prefixes will have >>> to >>>>>>> be subdivided. >>>>>>> >>>>>>> So a question for you is what else if anything will break? >>>>>>> >>>>>>> I also understand that you are suggesting that this be taken to >>> 6man. >>>>>>> That is a good suggestion. >>>>>>> >>>>>>> Curtis >>>>>>> >>>>>>> >>>>>>>> On 9/22/2012 11:30 PM, Curtis Villamizar wrote: >>>>>>>>> 12. This is sure to be controversial. I pointed out that >>> using >>>>>>>>> subnets longer than /64 is OK as long as they are not >>> leaked >>>>>>>>> into global routing. Please read the text and changes >>>>>> before >>>>>>>>> exploding on this topic. It may be necessary to subnet a >>>>>> /64 >>>>>>>> if >>>>>>>>> that is all a provider will give you and you need subnets. >>>>>> It >>>>>>>>> does work and it is no more unnatural than subnetting a >>>>>> class-A >>>>>>>>> network would be in 1990. It means using DHCPv6 and not >>>>>> using >>>>>>>>> RA prefixes for GUA (otherwise SLAAC implementations would >>>>>>>>> likely try to use the whole bottom 64). >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet > > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > From d.sturek@att.net Tue Sep 25 09:47: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 949E31F0CC1 for ; Tue, 25 Sep 2012 09:47:28 -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 5cJdSqIwxgyC for ; Tue, 25 Sep 2012 09:47:27 -0700 (PDT) Received: from nm23.bullet.mail.bf1.yahoo.com (nm23.bullet.mail.bf1.yahoo.com [98.139.212.182]) by ietfa.amsl.com (Postfix) with SMTP id 0727221F88ED for ; Tue, 25 Sep 2012 09:47:26 -0700 (PDT) Received: from [98.139.215.140] by nm23.bullet.mail.bf1.yahoo.com with NNFMP; 25 Sep 2012 16:47:26 -0000 Received: from [98.139.244.49] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 25 Sep 2012 16:47:26 -0000 Received: from [127.0.0.1] by smtp111.sbc.mail.bf1.yahoo.com with NNFMP; 25 Sep 2012 16:47:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1348591646; bh=aB2Fh+x40hr5iDoUpW3TlEptMajoF6raSywXPoXpRzY=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=sn8GkOP/95ah3vPQJtXHxIIuOHFGhbsM8U+54N3QGme0cNQkNH7ia8D0WDFfyX3fCnBqovyU37eLU5oOFHCPXD+iAOHTs8tivTV9MLP71AcTtPmJjjDN6Ytx6qK/WXOjP03G82CBRzIUKUtkNHFY63YNilc9xILL+HCF4xZ8wME= X-Yahoo-Newman-Id: 297078.74570.bm@smtp111.sbc.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: _qwNjeQVM1mpfAnvf0EJngHla8RtA.eXDmXkbPyFhTgCTF0 5YnSE4.J80qmyz1pDc9z3pPM5qv..WcHRXN70r_Kg9KwpNUtS5Oy2DJVmU_s bwpcQgB9lMNwWFLp5alWbjKNMqho9TeZG6BD4VQSolpDnLhZ6wgIGpzeveYG lBdwS_t7yU70dp2kVN0RKKw5YzKI2JAemC6Hk2DFib0fAb6KEYYauY06jb1o 0tHF0tnj3.NuHRjk.s5lCmwf.XHAQ.sU3wNYIr1TYTSuxh1DLMaJtrdIf6CV .VU3N2vW0smnnyJRMajvYsFoS8n0Aq96r9yf6ruwyhMKEYrB5JetQjMlbOzm gBvu5bBcXg6s1Kffci.nVrYU739RQeo5xiuiP_A7J2ZNy13WL91iKwyDvUjq sb4sOgjWPcUJ8cb2YJIM3tu95YOFCvyo5HdOW.MXyEgSxCLKYoHtksLv5pAk ShJ9mo9XhrFF1H7FZs7VPMAoH0cDJPzMa2NyYmldaQZmV7kI.ZrJeNwj.kYA xl13PiqDyXA-- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [10.1.1.105] (d.sturek@66.27.60.174 with login) by smtp111.sbc.mail.bf1.yahoo.com with SMTP; 25 Sep 2012 09:47:25 -0700 PDT User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Tue, 25 Sep 2012 09:47:22 -0700 From: Don Sturek To: , Message-ID: Thread-Topic: [homenet] draft-ietf-homenet-arch-04 In-Reply-To: <506171E1.1080802@gridmerge.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [homenet] draft-ietf-homenet-arch-04 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 16:47:28 -0000 Hi Robert, One more point touched on in your note below: 1) Ideally, it would be great if a single authorizatative device existed in the home providing DHCPv6 server services (if supported) and prefix delegation. One challenge in the description below is having multiple routers on multiple subnets, each possibly acting as a DHCPv6 server within their own subnet and also providing their own ULA prefix. We certainly don't want to further confuse address assignment in a setting where IT support does not exist. Don On 9/25/12 1:57 AM, "Robert Cragie" wrote: >So let's tweak Curtis' sequence slightly: > >What every host does is: > > if it has no MAC: > pick a random link local address > else > use the MAC to create a link local address > run DAD to make sure no one else has same address > > send a RS > > if it gets RA > use the RA prefix for SLAAC > else > time out and don't bother with SLAAC; can only use link local address > >then hopefully the host also does the following: > > send DHCPv6 client request > > if response > it has yet another address to pick from if it got one using SLAAC > else > time out and get nothing from DHCPv6 > >This should work fine for legacy APs where everything is bridged >underneath it. Where it gets interesting is in the case of cascaded >subnets behind a router connected to an ISP, where one or more of those >subnets may be a mesh network comprised of mesh routers and hosts. I am >not quite sure how ULAs and DHCPv6 would work in this case as there are >limitations as far as I can see (although I accept I probably have a bit >more reading to do on the subject). > >Robert > >On 25/09/2012 5:45 AM, Curtis Villamizar wrote: >> In message >> Don Sturek writes: >> >>> Hi Curtis, >>> >>> I think the difficulty is each device cannot "use the MAC to create a >>>ULA >>> address". Some authoritative device in the network (eg, the AP) must >>> create the ULA prefix. If a ULA prefix is not present because the AP >>>is a >>> legacy device not capable of providing a ULA prefix, the STA devices >>>must >>> use link locals only. >>> >>> Don >> >> Don, >> >> You are right about there being nothing to generate the ULA prefix in >> your example. My mistake. >> >> But it doesn't change anything. If the AP is a dumb bridge and there >> is no router of any kind, then link local addresses are perfectly >> fine. There is only one subnet in that example, and ULA is not >> needed. That was the example you gave. >> >> Your example had no router just an old AP that acted as a bridge, >> therefore nothing to generate any sort of RA. If there is a router >> and no GUA prefix (which is not your example, but a useful example), >> then ULA can be used. The only RA that is seen is the RA providing a >> ULA prefix which the router can generate. >> >> I did say that the possibility of having to subdivide a /64 only >> exists for GUA. If a router exists which gets a GUA from a provider, >> and there are more subnets than the prefix length can support the two >> options are the ones listed below. (Search for --or--). >> >> Curtis >> >> >>> On 9/24/12 6:52 PM, "Curtis Villamizar" wrote: >>> >>>> In message >>>> Don Sturek writes: >>>> >>>>> Hi Curtis, >>>>> >>>>> I would expect most Wi-Fi AP manufacturers to support the same >>>>>address >>>>> assignment they do today (ie, manual assignment and DHCP). I would >>>>> also expect as more IPv6 deployments happen that SLAAC will also be >>>>> supported (and, yes, even for GUA). >>>>> >>>>> For the types of devices which will be added to Wi-Fi networks in the >>>>> future (eg, headless devices like appliances, thermostats, etc.) that >>>>> the preferred address assignment will be SLAAC and DHCPv6 (and, yes, >>>>>I >>>>> purposely did not remove SLAAC.....) >>>>> >>>>> Don >>>> >>>> Don, >>>> >>>> We seem to be talking past each other so let me again try to be clear. >>>> >>>> What every host does is: >>>> >>>> if it has no MAC: >>>> pick a random link local (not ULA) address >>>> else >>>> use the MAC to create a ULA address >>>> run DAD to make sure no one else has same address >>>> >>>> send a RS >>>> >>>> if it gets RA >>>> use the RA prefix for SLAAC >>>> else >>>> time out and don't bother with SLAAC >>>> >>>> then hopefully the host also does the following: >>>> >>>> send DHCPv6 client request >>>> >>>> if response >>>> it has yet another address to pick from if it got one using SLAAC >>>> else >>>> time out and get nothing from DHCPv6 >>>> >>>> Note: new extensions to DHCPv6 allow the host to tell DHCPv6 server >>>> the address that it already has (from SLAAC). >>>> >>>> If as in the case of your Wi-Fi with a bridging AP example, there is >>>> no router to give it an DHCPv6 the link local or ULA addresses are >>>> still there and still usable. There is also no router to give it an >>>> RA response so it has no SLAAC assigned address and no DHCPv6 assigned >>>> address. >>>> >>>> That is the end of your example. >>>> >>>> If there is a router then there is something that can hand out a RA or >>>> DHCPv6 response. >>>> >>>> In the case were there exists multiple subnets and the CER has been >>>> granted a /64 (or too few /64s to handle the number of subnets), then: >>>> >>>> it can use RA with /64 on some subnets and give them GUA addresses >>>> and some subnets have no access outside the homenet >>>> >>>> --or-- >>>> >>>> it can not use RA (and therefore prevent SLAAC from being used) and >>>> hand out DHCPv6 addresses and make use of prefixes longer than /64. >>>> This prevents the use of CGA but get connectivity to the entire >>>> homenet. >>>> >>>> If every consumer oriented provider is willing to allocate prefixes >>>> shorter than /64 on request to home users, then the above situation >>>> never occurs. If it does, my argument is that the second option above >>>> is better than the first. >>>> >>>> Curtis >>>> >>>> >>>>> On 9/24/12 5:11 PM, "Curtis Villamizar" wrote: >>>>> >>>>>> In message <5060BDC7.6020403@freedesktop.org> >>>>>> Jim Gettys writes: >>>>>> >>>>>>> On 09/24/2012 03:17 PM, Don Sturek wrote: >>>>>>>> Hi Curtis, >>>>>>>> >>>>>>>> Here is the use case: >>>>>>>> 1) Customer has a legacy AP in their house >>>>>>>> 2) Customer brings home new devices supporting IPv6 (which are >>>>>>> designed >>>>>>>> to communicate only with other IPv6 based devices in the home) >>>>>>>> 3) The only way these new devices can communicate is through >>>>> address >>>>>>>> assignment using SLAAC and then some discovery method the two new >>>>>>> devices >>>>>>>> support (without support from the AP). Here these devices are >>>>>>> assuming >>>>>>>> bridging through the AP...... >>>>>>> >>>>>>> And since current legacy AP's all bridge, we win (even though we >>>>> need to >>>>>>> route in the future). >>>>>> Jim, >>>>>> >>>>>> The point was how do you get local IPv6 within the home with the >>>>>> legacy AP that does only IPv4 and just does bridging of IPv6. First >>>>>> of all you have no subnets. There is no CER to do DHCPv6. >>>>>> >>>>>> In this case you use link local or if everything has a MAC you can >>>>>>use >>>>>> ULA based on the MAC addressses. >>>>>> >>>>>>>> Placing a requirement that every customer who buys a new IPv6 >>>>> device, >>>>>>>> intended to communicate only with other IPv6 devices in the home, >>>>> will >>>>>>>> require a forklift upgrade of a deployed network in order to work >>>>>>> will not >>>>>>>> be popular. >>>>>>> >>>>>>> Good point. >>>>>> But invalid. The use case Don gave would still work fine. Only GUA >>>>>> addresses are affected. >>>>>> >>>>>>> I loathe DHCP (of any sort) *for basic address assignment, anyway* >>>>>>>in >>>>>>> the home environment. >>>>>>> >>>>>>> The loathing comes from the exquisite pain of suffering with a >>>>>>>flaky >>>>>>> home network for several months, before realising I had a rogue >>>>>>>DHCP >>>>>>> server somewhere on my network (from wireshark). I then had to >>>>>>>take >>>>> the >>>>>>> mac address, figure out who may have manufactured some device from >>>>> that >>>>>>> information, and finally figured out the little VOIP ATA adaptor I >>>>> had >>>>>>> been given liked to do DHCP. >>>>>> It did DHCP on the *WAN side*? You didn't put the rest of your >>>>>> network behind the VOIP box on the LAN side I hope. >>>>>> >>>>>>> This was by far the hardest debugging I've had to do in my home >>>>> network >>>>>>> in normal operation. >>>>>>> >>>>>>> This is well beyond normal home debugging capability of consumers. >>>>>>> - Jim >>>>>> We all have plenty of crappy IPv4 product horror stories. My VOIP >>>>>> phone locked up now and then and I figured out that if the call >>>>>>lasted >>>>>> longer than the DHCPv4 lease, then it lost the least because it >>>>>>didn't >>>>>> try to renew it. Not only did the call drop, but the device locked >>>>>> up. The first solution was to reboot it now and then. The answer >>>>>>was >>>>>> to configure a fixed address. I was lucky to figure it out before >>>>>>my >>>>>> wife threw the phone through a window. For all I know a later >>>>>> firmware upgrade might have fixed it. VOIP might be more popular if >>>>>> VOIP phones under $600 worked reasonably well. >>>>>> >>>>>> Both nice stories, but both are DHCPv4 related and have nothing at >>>>>>all >>>>>> to do with SLAAC. >>>>>> >>>>>> Curtis >>>>>> >>>>>>>> Don >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 9/24/12 11:49 AM, "Curtis Villamizar" wrote: >>>>>>>> >>>>>>>>> In message >>>>>>>>> Don Sturek writes: >>>>>>>>> >>>>>>>>>> Hi Curtis, >>>>>>>>>> >>>>>>>>>> SLAAC not working is a major problem. >>>>>>>>>> >>>>>>>>>> Don >>>>>>>>> Don, >>>>>>>>> >>>>>>>>> Why? This is an assertion without basis as far as I am >>>>>>>>>concerned. >>>>>>>>> Except CGA there is nothing that breaks without SLAAC. Joel >>>>> brought >>>>>>>>> up ILNP in private email, but I beleive ILNP can also work as the >>>>>>>>> constraints in ILNP are in the ILNP identifier which is not the >>>>> same >>>>>>>>> as the interface address in ILNP for which there is no >>>>>>>>>constraint. >>>>>>>>> >>>>>>>>> I have subnets running fine using a few /112 allocated from >>>>> within a >>>>>>>>> /64 with fixed addresses on rack mount hosts and desktops and >>>>> DHCPv6 >>>>>>>>> for dynamic allocations for laptops. It works fine. Link local >>>>>>>>> addresses are all that is needed to get DHCPv6 to work. No host >>>>> ever >>>>>>>>> receives a RA since my routers won't give them one, so no host >>>>> ever >>>>>>>>> tries to generate an address using SLAAC. The only constraint is >>>>>>> that >>>>>>>>> any host connecting to my Ethernet or wireless must run a DHCP >>>>> client >>>>>>>>> and if they want an IPv6 GUA must run a DHCPv6 client. DHCPv4 >>>>>>>>>and >>>>>>>>> DHCPv6 servers are available in every subnet except one GbE >>>>> subnet in >>>>>>>>> the rack and to a few hosts in my home office. >>>>>>>>> >>>>>>>>> So as far as I am concerned we have an assertion that no SLAAC is >>>>> a >>>>>>>>> problem and existance proof that it is not. Beside CGA and >>>>> requiring >>>>>>>>> that hosts run DHCPv6 if they want an IPv6 GUA, what can I not >>>>>>> support >>>>>>>>> on these /112 subnets? >>>>>>>>> >>>>>>>>> Curtis >>>>>>>>> >>>>>>>>> >>>>>>>>>> On 9/23/12 4:09 PM, "Curtis Villamizar" >>>>>>>>>>wrote: >>>>>>>>>> >>>>>>>>>>> In message <505E83F6.3030900@joelhalpern.com> >>>>>>>>>>> "Joel M. Halpern" writes: >>>>>>>>>>> >>>>>>>>>>>> Since you invited flames... >>>>>>>>>>>> >>>>>>>>>>>> The argument on /64 as the longest prefix is not that it is >>>>>>> magically >>>>>>>>>>>> unnatural. >>>>>>>>>>>> Rather, it is that there are a number of current and evolving >>>>>>>>>> protocols >>>>>>>>>>>> that depend upon that /64. The obvious example is that SLAAC >>>>> does >>>>>>>>>> not >>>>>>>>>>>> work if subnets are longer than /64. >>>>>>>>>>>> >>>>>>>>>>>> The rules in this regard are written into approved RFCs. If >>>>>>> homenet >>>>>>>>>>>> wants to change that, it really needs to go to 6man with a >>>>> strong >>>>>>>>>> case. >>>>>>>>>>>> (for point-to-point inter-router links this was recently >>>>>>> relaxed. >>>>>>>>>>>> >>>>>>>>>>>> At the same time, andy operator who insists on giving homes a >>>>> /64 >>>>>>> is >>>>>>>>>>>> being inappropriately restrictive. Homenet should say that, >>>>>>> rather >>>>>>>>>>>> than >>>>>>>>>>>> trying to change the IPv6 architecture. >>>>>>>>>>>> >>>>>>>>>>>> Yours, >>>>>>>>>>>> Joel >>>>>>>>>>> Joel, >>>>>>>>>>> >>>>>>>>>>> I don't consider your email a flame at all. Thanks for >>>>> responding. >>>>>>>>>>> SLAAC (which I am not at a fan of) won't work but DHCPv6 will >>>>>>>>>>>so >>>>>>> IMHO >>>>>>>>>>> no loss. CGA also won't work but then again I've also never >>>>> been a >>>>>>>>>>> fan of security half measures. Yes anti-spoofing without prior >>>>>>>>>>> exchange of a key is nice, but no reasonable authorization >>>>> could be >>>>>>>>>>> based on CGA without also exchanging some sort of key or cert >>>>> and >>>>>>> at >>>>>>>>>>> that point the CGA as a public key is redundant. >>>>>>>>>>> >>>>>>>>>>> If SLAAC and CGA are the only things that break *and* providers >>>>> do >>>>>>>>>>> hand out prefixes that are too small, then /64 prefixes will >>>>> have >>>>>>> to >>>>>>>>>>> be subdivided. >>>>>>>>>>> >>>>>>>>>>> So a question for you is what else if anything will break? >>>>>>>>>>> >>>>>>>>>>> I also understand that you are suggesting that this be taken to >>>>>>> 6man. >>>>>>>>>>> That is a good suggestion. >>>>>>>>>>> >>>>>>>>>>> Curtis >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> On 9/22/2012 11:30 PM, Curtis Villamizar wrote: >>>>>>>>>>>>> 12. This is sure to be controversial. I pointed out that >>>>>>> using >>>>>>>>>>>>> subnets longer than /64 is OK as long as they are not >>>>>>> leaked >>>>>>>>>>>>> into global routing. Please read the text and >>>>>>>>>>>>>changes >>>>>>>>>> before >>>>>>>>>>>>> exploding on this topic. It may be necessary to >>>>> subnet a >>>>>>>>>> /64 >>>>>>>>>>>> if >>>>>>>>>>>>> that is all a provider will give you and you need >>>>> subnets. >>>>>>>>>> It >>>>>>>>>>>>> does work and it is no more unnatural than >>>>>>>>>>>>>subnetting a >>>>>>>>>> class-A >>>>>>>>>>>>> network would be in 1990. It means using DHCPv6 and >>>>> not >>>>>>>>>> using >>>>>>>>>>>>> RA prefixes for GUA (otherwise SLAAC implementations >>>>> would >>>>>>>>>>>>> likely try to use the whole bottom 64). >>>>>> _______________________________________________ >>>>>> homenet mailing list >>>>>> homenet@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/homenet >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet >> > > >_______________________________________________ >homenet mailing list >homenet@ietf.org >https://www.ietf.org/mailman/listinfo/homenet From teco@inf-net.nl Tue Sep 25 12:34: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 1062D21F8971 for ; Tue, 25 Sep 2012 12:34:17 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ub34NCWasEEL for ; Tue, 25 Sep 2012 12:34:15 -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 4E7D021F8967 for ; Tue, 25 Sep 2012 12:34:14 -0700 (PDT) Received: by eekd4 with SMTP id d4so1362654eek.31 for ; Tue, 25 Sep 2012 12:34:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=CHyHZhB7su8WPhYvXDa7Pz0ChKyTvuVz7WzxuiXyqgQ=; b=B+vFotfSYTha2BTJS0rdH/m3sEbrvD6qH9xd5pXEEptYor7bF2Y2tS4lSeMIaDB1Kn nBvDVDkQUtrIP+JNWsin4C+0tmXzjKPg6bZ05fCKJHtNZZx/4iTGcC5+aPcYE9M9bkFX I1Nkakb8cZ31Lccw1bNIBLOVO5PesNxEXDkrQ0hMDkzn4ovC+KlLWpagUiE48o7pzSaf PrO61A6ih2gV3iK0dtrZ3EP4mP8YZVv65wXQl7A1oy4h+xztdITBLoPRpcBjLBJrMO7T 02dar3V3DE2rMGbE2j3Qy0FfZ4BpyS+1njgBk8Ik7hqNNbABI8w6AG/EitXKWM+144/X qRFA== Received: by 10.14.224.73 with SMTP id w49mr22288400eep.37.1348601653897; Tue, 25 Sep 2012 12:34:13 -0700 (PDT) Received: from ?IPv6:2001:470:7a9b:1:ece2:25ce:4317:ba7e? ([2001:470:7a9b:1:ece2:25ce:4317:ba7e]) by mx.google.com with ESMTPS id m42sm3361325eep.16.2012.09.25.12.34.12 (version=SSLv3 cipher=OTHER); Tue, 25 Sep 2012 12:34:13 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: Date: Tue, 25 Sep 2012 21:34:11 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: To: Don Sturek X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQnQK8wHQOYqsU3R0XoFz629jid7X/eVpGUTA0A6WnkJcb9Wmyv8k5kckN5xvszEaHwT4Xvz Cc: robert.cragie@gridmerge.com, homenet@ietf.org Subject: Re: [homenet] draft-ietf-homenet-arch-04 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 19:34:17 -0000 Op 25 sep. 2012, om 18:47 heeft Don Sturek het volgende geschreven: Sorry to jump in. > Hi Robert, > > One more point touched on in your note below: > 1) Ideally, it would be great if a single authorizatative device existed > in the home providing DHCPv6 server services (if supported) and prefix > delegation. I don't agree. When adding another gateway, to another ISP, I would like such to be independent form the existing gear. (3.2.2.2. B: Two ISPs, Two CERs, Shared subnet) > One challenge in the description below is having multiple routers on > multiple subnets, each possibly acting as a DHCPv6 server within their own > subnet and also providing their own ULA prefix. When hosts get their addresses for each RA prefix, by using SLAAC and/or DHCPv6, what is the challenge? (protocol-wise, not current host behavior) When hosts get only one GUA, they will use only one link to one ISP (no translation). For multi-path, this needs an update. > > We certainly don't want to further confuse address assignment in a setting > where IT support does not exist. Agreed, we need to improve address assignment. And routing based on destination & source addresses. Teco > > Don > > > > > On 9/25/12 1:57 AM, "Robert Cragie" wrote: > >> So let's tweak Curtis' sequence slightly: >> >> What every host does is: >> >> if it has no MAC: >> pick a random link local address >> else >> use the MAC to create a link local address >> run DAD to make sure no one else has same address >> >> send a RS >> >> if it gets RA >> use the RA prefix for SLAAC >> else >> time out and don't bother with SLAAC; can only use link local address >> >> then hopefully the host also does the following: >> >> send DHCPv6 client request >> >> if response >> it has yet another address to pick from if it got one using SLAAC >> else >> time out and get nothing from DHCPv6 >> >> This should work fine for legacy APs where everything is bridged >> underneath it. Where it gets interesting is in the case of cascaded >> subnets behind a router connected to an ISP, where one or more of those >> subnets may be a mesh network comprised of mesh routers and hosts. I am >> not quite sure how ULAs and DHCPv6 would work in this case as there are >> limitations as far as I can see (although I accept I probably have a bit >> more reading to do on the subject). >> >> Robert >> >> On 25/09/2012 5:45 AM, Curtis Villamizar wrote: >>> In message >>> Don Sturek writes: >>> >>>> Hi Curtis, >>>> >>>> I think the difficulty is each device cannot "use the MAC to create a >>>> ULA >>>> address". Some authoritative device in the network (eg, the AP) must >>>> create the ULA prefix. If a ULA prefix is not present because the AP >>>> is a >>>> legacy device not capable of providing a ULA prefix, the STA devices >>>> must >>>> use link locals only. >>>> >>>> Don >>> >>> Don, >>> >>> You are right about there being nothing to generate the ULA prefix in >>> your example. My mistake. >>> >>> But it doesn't change anything. If the AP is a dumb bridge and there >>> is no router of any kind, then link local addresses are perfectly >>> fine. There is only one subnet in that example, and ULA is not >>> needed. That was the example you gave. >>> >>> Your example had no router just an old AP that acted as a bridge, >>> therefore nothing to generate any sort of RA. If there is a router >>> and no GUA prefix (which is not your example, but a useful example), >>> then ULA can be used. The only RA that is seen is the RA providing a >>> ULA prefix which the router can generate. >>> >>> I did say that the possibility of having to subdivide a /64 only >>> exists for GUA. If a router exists which gets a GUA from a provider, >>> and there are more subnets than the prefix length can support the two >>> options are the ones listed below. (Search for --or--). >>> >>> Curtis >>> >>> >>>> On 9/24/12 6:52 PM, "Curtis Villamizar" wrote: >>>> >>>>> In message >>>>> Don Sturek writes: >>>>> >>>>>> Hi Curtis, >>>>>> >>>>>> I would expect most Wi-Fi AP manufacturers to support the same >>>>>> address >>>>>> assignment they do today (ie, manual assignment and DHCP). I would >>>>>> also expect as more IPv6 deployments happen that SLAAC will also be >>>>>> supported (and, yes, even for GUA). >>>>>> >>>>>> For the types of devices which will be added to Wi-Fi networks in the >>>>>> future (eg, headless devices like appliances, thermostats, etc.) that >>>>>> the preferred address assignment will be SLAAC and DHCPv6 (and, yes, >>>>>> I >>>>>> purposely did not remove SLAAC.....) >>>>>> >>>>>> Don >>>>> >>>>> Don, >>>>> >>>>> We seem to be talking past each other so let me again try to be clear. >>>>> >>>>> What every host does is: >>>>> >>>>> if it has no MAC: >>>>> pick a random link local (not ULA) address >>>>> else >>>>> use the MAC to create a ULA address >>>>> run DAD to make sure no one else has same address >>>>> >>>>> send a RS >>>>> >>>>> if it gets RA >>>>> use the RA prefix for SLAAC >>>>> else >>>>> time out and don't bother with SLAAC >>>>> >>>>> then hopefully the host also does the following: >>>>> >>>>> send DHCPv6 client request >>>>> >>>>> if response >>>>> it has yet another address to pick from if it got one using SLAAC >>>>> else >>>>> time out and get nothing from DHCPv6 >>>>> >>>>> Note: new extensions to DHCPv6 allow the host to tell DHCPv6 server >>>>> the address that it already has (from SLAAC). >>>>> >>>>> If as in the case of your Wi-Fi with a bridging AP example, there is >>>>> no router to give it an DHCPv6 the link local or ULA addresses are >>>>> still there and still usable. There is also no router to give it an >>>>> RA response so it has no SLAAC assigned address and no DHCPv6 assigned >>>>> address. >>>>> >>>>> That is the end of your example. >>>>> >>>>> If there is a router then there is something that can hand out a RA or >>>>> DHCPv6 response. >>>>> >>>>> In the case were there exists multiple subnets and the CER has been >>>>> granted a /64 (or too few /64s to handle the number of subnets), then: >>>>> >>>>> it can use RA with /64 on some subnets and give them GUA addresses >>>>> and some subnets have no access outside the homenet >>>>> >>>>> --or-- >>>>> >>>>> it can not use RA (and therefore prevent SLAAC from being used) and >>>>> hand out DHCPv6 addresses and make use of prefixes longer than /64. >>>>> This prevents the use of CGA but get connectivity to the entire >>>>> homenet. >>>>> >>>>> If every consumer oriented provider is willing to allocate prefixes >>>>> shorter than /64 on request to home users, then the above situation >>>>> never occurs. If it does, my argument is that the second option above >>>>> is better than the first. >>>>> >>>>> Curtis >>>>> >>>>> >>>>>> On 9/24/12 5:11 PM, "Curtis Villamizar" wrote: >>>>>> >>>>>>> In message <5060BDC7.6020403@freedesktop.org> >>>>>>> Jim Gettys writes: >>>>>>> >>>>>>>> On 09/24/2012 03:17 PM, Don Sturek wrote: >>>>>>>>> Hi Curtis, >>>>>>>>> >>>>>>>>> Here is the use case: >>>>>>>>> 1) Customer has a legacy AP in their house >>>>>>>>> 2) Customer brings home new devices supporting IPv6 (which are >>>>>>>> designed >>>>>>>>> to communicate only with other IPv6 based devices in the home) >>>>>>>>> 3) The only way these new devices can communicate is through >>>>>> address >>>>>>>>> assignment using SLAAC and then some discovery method the two new >>>>>>>> devices >>>>>>>>> support (without support from the AP). Here these devices are >>>>>>>> assuming >>>>>>>>> bridging through the AP...... >>>>>>>> >>>>>>>> And since current legacy AP's all bridge, we win (even though we >>>>>> need to >>>>>>>> route in the future). >>>>>>> Jim, >>>>>>> >>>>>>> The point was how do you get local IPv6 within the home with the >>>>>>> legacy AP that does only IPv4 and just does bridging of IPv6. First >>>>>>> of all you have no subnets. There is no CER to do DHCPv6. >>>>>>> >>>>>>> In this case you use link local or if everything has a MAC you can >>>>>>> use >>>>>>> ULA based on the MAC addressses. >>>>>>> >>>>>>>>> Placing a requirement that every customer who buys a new IPv6 >>>>>> device, >>>>>>>>> intended to communicate only with other IPv6 devices in the home, >>>>>> will >>>>>>>>> require a forklift upgrade of a deployed network in order to work >>>>>>>> will not >>>>>>>>> be popular. >>>>>>>> >>>>>>>> Good point. >>>>>>> But invalid. The use case Don gave would still work fine. Only GUA >>>>>>> addresses are affected. >>>>>>> >>>>>>>> I loathe DHCP (of any sort) *for basic address assignment, anyway* >>>>>>>> in >>>>>>>> the home environment. >>>>>>>> >>>>>>>> The loathing comes from the exquisite pain of suffering with a >>>>>>>> flaky >>>>>>>> home network for several months, before realising I had a rogue >>>>>>>> DHCP >>>>>>>> server somewhere on my network (from wireshark). I then had to >>>>>>>> take >>>>>> the >>>>>>>> mac address, figure out who may have manufactured some device from >>>>>> that >>>>>>>> information, and finally figured out the little VOIP ATA adaptor I >>>>>> had >>>>>>>> been given liked to do DHCP. >>>>>>> It did DHCP on the *WAN side*? You didn't put the rest of your >>>>>>> network behind the VOIP box on the LAN side I hope. >>>>>>> >>>>>>>> This was by far the hardest debugging I've had to do in my home >>>>>> network >>>>>>>> in normal operation. >>>>>>>> >>>>>>>> This is well beyond normal home debugging capability of consumers. >>>>>>>> - Jim >>>>>>> We all have plenty of crappy IPv4 product horror stories. My VOIP >>>>>>> phone locked up now and then and I figured out that if the call >>>>>>> lasted >>>>>>> longer than the DHCPv4 lease, then it lost the least because it >>>>>>> didn't >>>>>>> try to renew it. Not only did the call drop, but the device locked >>>>>>> up. The first solution was to reboot it now and then. The answer >>>>>>> was >>>>>>> to configure a fixed address. I was lucky to figure it out before >>>>>>> my >>>>>>> wife threw the phone through a window. For all I know a later >>>>>>> firmware upgrade might have fixed it. VOIP might be more popular if >>>>>>> VOIP phones under $600 worked reasonably well. >>>>>>> >>>>>>> Both nice stories, but both are DHCPv4 related and have nothing at >>>>>>> all >>>>>>> to do with SLAAC. >>>>>>> >>>>>>> Curtis >>>>>>> >>>>>>>>> Don >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 9/24/12 11:49 AM, "Curtis Villamizar" wrote: >>>>>>>>> >>>>>>>>>> In message >>>>>>>>>> Don Sturek writes: >>>>>>>>>> >>>>>>>>>>> Hi Curtis, >>>>>>>>>>> >>>>>>>>>>> SLAAC not working is a major problem. >>>>>>>>>>> >>>>>>>>>>> Don >>>>>>>>>> Don, >>>>>>>>>> >>>>>>>>>> Why? This is an assertion without basis as far as I am >>>>>>>>>> concerned. >>>>>>>>>> Except CGA there is nothing that breaks without SLAAC. Joel >>>>>> brought >>>>>>>>>> up ILNP in private email, but I beleive ILNP can also work as the >>>>>>>>>> constraints in ILNP are in the ILNP identifier which is not the >>>>>> same >>>>>>>>>> as the interface address in ILNP for which there is no >>>>>>>>>> constraint. >>>>>>>>>> >>>>>>>>>> I have subnets running fine using a few /112 allocated from >>>>>> within a >>>>>>>>>> /64 with fixed addresses on rack mount hosts and desktops and >>>>>> DHCPv6 >>>>>>>>>> for dynamic allocations for laptops. It works fine. Link local >>>>>>>>>> addresses are all that is needed to get DHCPv6 to work. No host >>>>>> ever >>>>>>>>>> receives a RA since my routers won't give them one, so no host >>>>>> ever >>>>>>>>>> tries to generate an address using SLAAC. The only constraint is >>>>>>>> that >>>>>>>>>> any host connecting to my Ethernet or wireless must run a DHCP >>>>>> client >>>>>>>>>> and if they want an IPv6 GUA must run a DHCPv6 client. DHCPv4 >>>>>>>>>> and >>>>>>>>>> DHCPv6 servers are available in every subnet except one GbE >>>>>> subnet in >>>>>>>>>> the rack and to a few hosts in my home office. >>>>>>>>>> >>>>>>>>>> So as far as I am concerned we have an assertion that no SLAAC is >>>>>> a >>>>>>>>>> problem and existance proof that it is not. Beside CGA and >>>>>> requiring >>>>>>>>>> that hosts run DHCPv6 if they want an IPv6 GUA, what can I not >>>>>>>> support >>>>>>>>>> on these /112 subnets? >>>>>>>>>> >>>>>>>>>> Curtis >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On 9/23/12 4:09 PM, "Curtis Villamizar" >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> In message <505E83F6.3030900@joelhalpern.com> >>>>>>>>>>>> "Joel M. Halpern" writes: >>>>>>>>>>>> >>>>>>>>>>>>> Since you invited flames... >>>>>>>>>>>>> >>>>>>>>>>>>> The argument on /64 as the longest prefix is not that it is >>>>>>>> magically >>>>>>>>>>>>> unnatural. >>>>>>>>>>>>> Rather, it is that there are a number of current and evolving >>>>>>>>>>> protocols >>>>>>>>>>>>> that depend upon that /64. The obvious example is that SLAAC >>>>>> does >>>>>>>>>>> not >>>>>>>>>>>>> work if subnets are longer than /64. >>>>>>>>>>>>> >>>>>>>>>>>>> The rules in this regard are written into approved RFCs. If >>>>>>>> homenet >>>>>>>>>>>>> wants to change that, it really needs to go to 6man with a >>>>>> strong >>>>>>>>>>> case. >>>>>>>>>>>>> (for point-to-point inter-router links this was recently >>>>>>>> relaxed. >>>>>>>>>>>>> >>>>>>>>>>>>> At the same time, andy operator who insists on giving homes a >>>>>> /64 >>>>>>>> is >>>>>>>>>>>>> being inappropriately restrictive. Homenet should say that, >>>>>>>> rather >>>>>>>>>>>>> than >>>>>>>>>>>>> trying to change the IPv6 architecture. >>>>>>>>>>>>> >>>>>>>>>>>>> Yours, >>>>>>>>>>>>> Joel >>>>>>>>>>>> Joel, >>>>>>>>>>>> >>>>>>>>>>>> I don't consider your email a flame at all. Thanks for >>>>>> responding. >>>>>>>>>>>> SLAAC (which I am not at a fan of) won't work but DHCPv6 will >>>>>>>>>>>> so >>>>>>>> IMHO >>>>>>>>>>>> no loss. CGA also won't work but then again I've also never >>>>>> been a >>>>>>>>>>>> fan of security half measures. Yes anti-spoofing without prior >>>>>>>>>>>> exchange of a key is nice, but no reasonable authorization >>>>>> could be >>>>>>>>>>>> based on CGA without also exchanging some sort of key or cert >>>>>> and >>>>>>>> at >>>>>>>>>>>> that point the CGA as a public key is redundant. >>>>>>>>>>>> >>>>>>>>>>>> If SLAAC and CGA are the only things that break *and* providers >>>>>> do >>>>>>>>>>>> hand out prefixes that are too small, then /64 prefixes will >>>>>> have >>>>>>>> to >>>>>>>>>>>> be subdivided. >>>>>>>>>>>> >>>>>>>>>>>> So a question for you is what else if anything will break? >>>>>>>>>>>> >>>>>>>>>>>> I also understand that you are suggesting that this be taken to >>>>>>>> 6man. >>>>>>>>>>>> That is a good suggestion. >>>>>>>>>>>> >>>>>>>>>>>> Curtis >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> On 9/22/2012 11:30 PM, Curtis Villamizar wrote: >>>>>>>>>>>>>> 12. This is sure to be controversial. I pointed out that >>>>>>>> using >>>>>>>>>>>>>> subnets longer than /64 is OK as long as they are not >>>>>>>> leaked >>>>>>>>>>>>>> into global routing. Please read the text and >>>>>>>>>>>>>> changes >>>>>>>>>>> before >>>>>>>>>>>>>> exploding on this topic. It may be necessary to >>>>>> subnet a >>>>>>>>>>> /64 >>>>>>>>>>>>> if >>>>>>>>>>>>>> that is all a provider will give you and you need >>>>>> subnets. >>>>>>>>>>> It >>>>>>>>>>>>>> does work and it is no more unnatural than >>>>>>>>>>>>>> subnetting a >>>>>>>>>>> class-A >>>>>>>>>>>>>> network would be in 1990. It means using DHCPv6 and >>>>>> not >>>>>>>>>>> using >>>>>>>>>>>>>> RA prefixes for GUA (otherwise SLAAC implementations >>>>>> would >>>>>>>>>>>>>> likely try to use the whole bottom 64). >>>>>>> _______________________________________________ >>>>>>> homenet mailing list >>>>>>> homenet@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/homenet >>> _______________________________________________ >>> homenet mailing list >>> homenet@ietf.org >>> https://www.ietf.org/mailman/listinfo/homenet >>> >> >> >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet > > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From d.sturek@att.net Tue Sep 25 12:55: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 EB1961F0CD2 for ; Tue, 25 Sep 2012 12:55:28 -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 m9Aki6VJSL75 for ; Tue, 25 Sep 2012 12:55:27 -0700 (PDT) Received: from nm7.bullet.mail.bf1.yahoo.com (nm7.bullet.mail.bf1.yahoo.com [98.139.212.166]) by ietfa.amsl.com (Postfix) with SMTP id 4A37921F85ED for ; Tue, 25 Sep 2012 12:55:26 -0700 (PDT) Received: from [98.139.212.151] by nm7.bullet.mail.bf1.yahoo.com with NNFMP; 25 Sep 2012 19:55:26 -0000 Received: from [98.139.221.53] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 25 Sep 2012 19:55:26 -0000 Received: from [127.0.0.1] by smtp106.sbc.mail.bf1.yahoo.com with NNFMP; 25 Sep 2012 19:55:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1348602926; bh=RijkuTcVp0TzzVypl5N309ixJmo+DyUTVBA7l+iPEOk=; 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=GMb8xspDaJ79m8L5Ppl3SuwTej9LGy/VEB60ywzzt7yYsvtZP8tZiMDRbVZfAPB+KOCdVyEzsdehrnU137MPGZDnmtx2ZiykgTe4EI84G2HMTKoqGItkms+9eAGeSgDENhLbzyizBNjSUtwk9o8vi966VvufsU14oNhT+U+V8S4= X-Yahoo-Newman-Id: 95242.72563.bm@smtp106.sbc.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: Mp7oa98VM1nqWeljVcrEhELYNxelrK7CkB1d97bOBlKfVZy iKoGyg0mIcbpxWM9W.pGAbsl5GYz4YPMAy1ucw8Uh7clKY1MNPlvGfny.Wjb v6SWP6dp6KisoqHfZN1DFdoA7YjXS14EEcX1OuD.TaILK_3xicG6kVaK.zeU Qo64eym179iGh20ei.zq5eASb0YnjJ9DEaP3KRKXcDwEzsPCFWqS1lLW5rqx hl966hrYgN1OVUqHRwhrO1CCLYY5P2Ks5FXRdZb7IpKrbuzf1dg6OxsaI9HK RzopaC9T9Egj1IKHXcgTk0YOlxj0oQgNaYAISMyXsA89tIo5wX7Q1bcTC0fY AmOEGC0srh9bLOFsKNRcWRYiUcbbw61ay5AxGIVOjlbPbUt_N5OHe1rsMK6G FVDzQxDev1fgrvfUfN2DVhgF6t1Cb2N6Jt.t1EmQgvfN.aPRQiXed9s5HwGW d_0.hfMkzeaQfINnews8u7PFCTCX8OaEqY0tjmXFR0LP6cUFQjAcImLmFo78 wz90o_caapw-- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [10.1.1.105] (d.sturek@66.27.60.174 with login) by smtp106.sbc.mail.bf1.yahoo.com with SMTP; 25 Sep 2012 12:55:24 -0700 PDT User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Tue, 25 Sep 2012 12:55:20 -0700 From: Don Sturek To: Teco Boot Message-ID: Thread-Topic: [homenet] draft-ietf-homenet-arch-04 In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: robert.cragie@gridmerge.com, homenet@ietf.org Subject: Re: [homenet] draft-ietf-homenet-arch-04 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 19:55:29 -0000 Hi Teco, The main requirement I see is that a home network with multiple ISP connections, multiple CERs and a shared subnet must support the ability to discover services within the entire site (home) despite having devices with differing ULA prefixes and GUA prefixes. How would you see discovery working in such a home network? Don On 9/25/12 12:34 PM, "Teco Boot" wrote: >Op 25 sep. 2012, om 18:47 heeft Don Sturek het volgende geschreven: > >Sorry to jump in. > >> Hi Robert, >> >> One more point touched on in your note below: >> 1) Ideally, it would be great if a single authorizatative device >>existed >> in the home providing DHCPv6 server services (if supported) and prefix >> delegation. >I don't agree. When adding another gateway, to another ISP, I would like >such to be independent form the existing gear. >(3.2.2.2. B: Two ISPs, Two CERs, Shared subnet) > > >> One challenge in the description below is having multiple routers on >> multiple subnets, each possibly acting as a DHCPv6 server within their >>own >> subnet and also providing their own ULA prefix. >When hosts get their addresses for each RA prefix, by using SLAAC and/or >DHCPv6, what is the challenge? (protocol-wise, not current host behavior) > >When hosts get only one GUA, they will use only one link to one ISP (no >translation). For multi-path, this needs an update. > >> >> We certainly don't want to further confuse address assignment in a >>setting >> where IT support does not exist. >Agreed, we need to improve address assignment. And routing based on >destination & source addresses. > >Teco > >> >> Don >> >> >> >> >> On 9/25/12 1:57 AM, "Robert Cragie" wrote: >> >>> So let's tweak Curtis' sequence slightly: >>> >>> What every host does is: >>> >>> if it has no MAC: >>> pick a random link local address >>> else >>> use the MAC to create a link local address >>> run DAD to make sure no one else has same address >>> >>> send a RS >>> >>> if it gets RA >>> use the RA prefix for SLAAC >>> else >>> time out and don't bother with SLAAC; can only use link local address >>> >>> then hopefully the host also does the following: >>> >>> send DHCPv6 client request >>> >>> if response >>> it has yet another address to pick from if it got one using SLAAC >>> else >>> time out and get nothing from DHCPv6 >>> >>> This should work fine for legacy APs where everything is bridged >>> underneath it. Where it gets interesting is in the case of cascaded >>> subnets behind a router connected to an ISP, where one or more of those >>> subnets may be a mesh network comprised of mesh routers and hosts. I am >>> not quite sure how ULAs and DHCPv6 would work in this case as there are >>> limitations as far as I can see (although I accept I probably have a >>>bit >>> more reading to do on the subject). >>> >>> Robert >>> >>> On 25/09/2012 5:45 AM, Curtis Villamizar wrote: >>>> In message >>>> Don Sturek writes: >>>> >>>>> Hi Curtis, >>>>> >>>>> I think the difficulty is each device cannot "use the MAC to create a >>>>> ULA >>>>> address". Some authoritative device in the network (eg, the AP) must >>>>> create the ULA prefix. If a ULA prefix is not present because the AP >>>>> is a >>>>> legacy device not capable of providing a ULA prefix, the STA devices >>>>> must >>>>> use link locals only. >>>>> >>>>> Don >>>> >>>> Don, >>>> >>>> You are right about there being nothing to generate the ULA prefix in >>>> your example. My mistake. >>>> >>>> But it doesn't change anything. If the AP is a dumb bridge and there >>>> is no router of any kind, then link local addresses are perfectly >>>> fine. There is only one subnet in that example, and ULA is not >>>> needed. That was the example you gave. >>>> >>>> Your example had no router just an old AP that acted as a bridge, >>>> therefore nothing to generate any sort of RA. If there is a router >>>> and no GUA prefix (which is not your example, but a useful example), >>>> then ULA can be used. The only RA that is seen is the RA providing a >>>> ULA prefix which the router can generate. >>>> >>>> I did say that the possibility of having to subdivide a /64 only >>>> exists for GUA. If a router exists which gets a GUA from a provider, >>>> and there are more subnets than the prefix length can support the two >>>> options are the ones listed below. (Search for --or--). >>>> >>>> Curtis >>>> >>>> >>>>> On 9/24/12 6:52 PM, "Curtis Villamizar" wrote: >>>>> >>>>>> In message >>>>>> Don Sturek writes: >>>>>> >>>>>>> Hi Curtis, >>>>>>> >>>>>>> I would expect most Wi-Fi AP manufacturers to support the same >>>>>>> address >>>>>>> assignment they do today (ie, manual assignment and DHCP). I would >>>>>>> also expect as more IPv6 deployments happen that SLAAC will also be >>>>>>> supported (and, yes, even for GUA). >>>>>>> >>>>>>> For the types of devices which will be added to Wi-Fi networks in >>>>>>>the >>>>>>> future (eg, headless devices like appliances, thermostats, etc.) >>>>>>>that >>>>>>> the preferred address assignment will be SLAAC and DHCPv6 (and, >>>>>>>yes, >>>>>>> I >>>>>>> purposely did not remove SLAAC.....) >>>>>>> >>>>>>> Don >>>>>> >>>>>> Don, >>>>>> >>>>>> We seem to be talking past each other so let me again try to be >>>>>>clear. >>>>>> >>>>>> What every host does is: >>>>>> >>>>>> if it has no MAC: >>>>>> pick a random link local (not ULA) address >>>>>> else >>>>>> use the MAC to create a ULA address >>>>>> run DAD to make sure no one else has same address >>>>>> >>>>>> send a RS >>>>>> >>>>>> if it gets RA >>>>>> use the RA prefix for SLAAC >>>>>> else >>>>>> time out and don't bother with SLAAC >>>>>> >>>>>> then hopefully the host also does the following: >>>>>> >>>>>> send DHCPv6 client request >>>>>> >>>>>> if response >>>>>> it has yet another address to pick from if it got one using SLAAC >>>>>> else >>>>>> time out and get nothing from DHCPv6 >>>>>> >>>>>> Note: new extensions to DHCPv6 allow the host to tell DHCPv6 server >>>>>> the address that it already has (from SLAAC). >>>>>> >>>>>> If as in the case of your Wi-Fi with a bridging AP example, there is >>>>>> no router to give it an DHCPv6 the link local or ULA addresses are >>>>>> still there and still usable. There is also no router to give it an >>>>>> RA response so it has no SLAAC assigned address and no DHCPv6 >>>>>>assigned >>>>>> address. >>>>>> >>>>>> That is the end of your example. >>>>>> >>>>>> If there is a router then there is something that can hand out a RA >>>>>>or >>>>>> DHCPv6 response. >>>>>> >>>>>> In the case were there exists multiple subnets and the CER has been >>>>>> granted a /64 (or too few /64s to handle the number of subnets), >>>>>>then: >>>>>> >>>>>> it can use RA with /64 on some subnets and give them GUA addresses >>>>>> and some subnets have no access outside the homenet >>>>>> >>>>>> --or-- >>>>>> >>>>>> it can not use RA (and therefore prevent SLAAC from being used) and >>>>>> hand out DHCPv6 addresses and make use of prefixes longer than /64. >>>>>> This prevents the use of CGA but get connectivity to the entire >>>>>> homenet. >>>>>> >>>>>> If every consumer oriented provider is willing to allocate prefixes >>>>>> shorter than /64 on request to home users, then the above situation >>>>>> never occurs. If it does, my argument is that the second option >>>>>>above >>>>>> is better than the first. >>>>>> >>>>>> Curtis >>>>>> >>>>>> >>>>>>> On 9/24/12 5:11 PM, "Curtis Villamizar" wrote: >>>>>>> >>>>>>>> In message <5060BDC7.6020403@freedesktop.org> >>>>>>>> Jim Gettys writes: >>>>>>>> >>>>>>>>> On 09/24/2012 03:17 PM, Don Sturek wrote: >>>>>>>>>> Hi Curtis, >>>>>>>>>> >>>>>>>>>> Here is the use case: >>>>>>>>>> 1) Customer has a legacy AP in their house >>>>>>>>>> 2) Customer brings home new devices supporting IPv6 (which are >>>>>>>>> designed >>>>>>>>>> to communicate only with other IPv6 based devices in the home) >>>>>>>>>> 3) The only way these new devices can communicate is through >>>>>>> address >>>>>>>>>> assignment using SLAAC and then some discovery method the two >>>>>>>>>>new >>>>>>>>> devices >>>>>>>>>> support (without support from the AP). Here these devices are >>>>>>>>> assuming >>>>>>>>>> bridging through the AP...... >>>>>>>>> >>>>>>>>> And since current legacy AP's all bridge, we win (even though we >>>>>>> need to >>>>>>>>> route in the future). >>>>>>>> Jim, >>>>>>>> >>>>>>>> The point was how do you get local IPv6 within the home with the >>>>>>>> legacy AP that does only IPv4 and just does bridging of IPv6. >>>>>>>>First >>>>>>>> of all you have no subnets. There is no CER to do DHCPv6. >>>>>>>> >>>>>>>> In this case you use link local or if everything has a MAC you can >>>>>>>> use >>>>>>>> ULA based on the MAC addressses. >>>>>>>> >>>>>>>>>> Placing a requirement that every customer who buys a new IPv6 >>>>>>> device, >>>>>>>>>> intended to communicate only with other IPv6 devices in the >>>>>>>>>>home, >>>>>>> will >>>>>>>>>> require a forklift upgrade of a deployed network in order to >>>>>>>>>>work >>>>>>>>> will not >>>>>>>>>> be popular. >>>>>>>>> >>>>>>>>> Good point. >>>>>>>> But invalid. The use case Don gave would still work fine. Only >>>>>>>>GUA >>>>>>>> addresses are affected. >>>>>>>> >>>>>>>>> I loathe DHCP (of any sort) *for basic address assignment, >>>>>>>>>anyway* >>>>>>>>> in >>>>>>>>> the home environment. >>>>>>>>> >>>>>>>>> The loathing comes from the exquisite pain of suffering with a >>>>>>>>> flaky >>>>>>>>> home network for several months, before realising I had a rogue >>>>>>>>> DHCP >>>>>>>>> server somewhere on my network (from wireshark). I then had to >>>>>>>>> take >>>>>>> the >>>>>>>>> mac address, figure out who may have manufactured some device >>>>>>>>>from >>>>>>> that >>>>>>>>> information, and finally figured out the little VOIP ATA adaptor >>>>>>>>>I >>>>>>> had >>>>>>>>> been given liked to do DHCP. >>>>>>>> It did DHCP on the *WAN side*? You didn't put the rest of your >>>>>>>> network behind the VOIP box on the LAN side I hope. >>>>>>>> >>>>>>>>> This was by far the hardest debugging I've had to do in my home >>>>>>> network >>>>>>>>> in normal operation. >>>>>>>>> >>>>>>>>> This is well beyond normal home debugging capability of >>>>>>>>>consumers. >>>>>>>>> - Jim >>>>>>>> We all have plenty of crappy IPv4 product horror stories. My VOIP >>>>>>>> phone locked up now and then and I figured out that if the call >>>>>>>> lasted >>>>>>>> longer than the DHCPv4 lease, then it lost the least because it >>>>>>>> didn't >>>>>>>> try to renew it. Not only did the call drop, but the device >>>>>>>>locked >>>>>>>> up. The first solution was to reboot it now and then. The answer >>>>>>>> was >>>>>>>> to configure a fixed address. I was lucky to figure it out before >>>>>>>> my >>>>>>>> wife threw the phone through a window. For all I know a later >>>>>>>> firmware upgrade might have fixed it. VOIP might be more popular >>>>>>>>if >>>>>>>> VOIP phones under $600 worked reasonably well. >>>>>>>> >>>>>>>> Both nice stories, but both are DHCPv4 related and have nothing at >>>>>>>> all >>>>>>>> to do with SLAAC. >>>>>>>> >>>>>>>> Curtis >>>>>>>> >>>>>>>>>> Don >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 9/24/12 11:49 AM, "Curtis Villamizar" >>>>>>>>>>wrote: >>>>>>>>>> >>>>>>>>>>> In message >>>>>>>>>>> Don Sturek writes: >>>>>>>>>>> >>>>>>>>>>>> Hi Curtis, >>>>>>>>>>>> >>>>>>>>>>>> SLAAC not working is a major problem. >>>>>>>>>>>> >>>>>>>>>>>> Don >>>>>>>>>>> Don, >>>>>>>>>>> >>>>>>>>>>> Why? This is an assertion without basis as far as I am >>>>>>>>>>> concerned. >>>>>>>>>>> Except CGA there is nothing that breaks without SLAAC. Joel >>>>>>> brought >>>>>>>>>>> up ILNP in private email, but I beleive ILNP can also work as >>>>>>>>>>>the >>>>>>>>>>> constraints in ILNP are in the ILNP identifier which is not the >>>>>>> same >>>>>>>>>>> as the interface address in ILNP for which there is no >>>>>>>>>>> constraint. >>>>>>>>>>> >>>>>>>>>>> I have subnets running fine using a few /112 allocated from >>>>>>> within a >>>>>>>>>>> /64 with fixed addresses on rack mount hosts and desktops and >>>>>>> DHCPv6 >>>>>>>>>>> for dynamic allocations for laptops. It works fine. Link >>>>>>>>>>>local >>>>>>>>>>> addresses are all that is needed to get DHCPv6 to work. No >>>>>>>>>>>host >>>>>>> ever >>>>>>>>>>> receives a RA since my routers won't give them one, so no host >>>>>>> ever >>>>>>>>>>> tries to generate an address using SLAAC. The only constraint >>>>>>>>>>>is >>>>>>>>> that >>>>>>>>>>> any host connecting to my Ethernet or wireless must run a DHCP >>>>>>> client >>>>>>>>>>> and if they want an IPv6 GUA must run a DHCPv6 client. DHCPv4 >>>>>>>>>>> and >>>>>>>>>>> DHCPv6 servers are available in every subnet except one GbE >>>>>>> subnet in >>>>>>>>>>> the rack and to a few hosts in my home office. >>>>>>>>>>> >>>>>>>>>>> So as far as I am concerned we have an assertion that no SLAAC >>>>>>>>>>>is >>>>>>> a >>>>>>>>>>> problem and existance proof that it is not. Beside CGA and >>>>>>> requiring >>>>>>>>>>> that hosts run DHCPv6 if they want an IPv6 GUA, what can I not >>>>>>>>> support >>>>>>>>>>> on these /112 subnets? >>>>>>>>>>> >>>>>>>>>>> Curtis >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> On 9/23/12 4:09 PM, "Curtis Villamizar" >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> In message <505E83F6.3030900@joelhalpern.com> >>>>>>>>>>>>> "Joel M. Halpern" writes: >>>>>>>>>>>>> >>>>>>>>>>>>>> Since you invited flames... >>>>>>>>>>>>>> >>>>>>>>>>>>>> The argument on /64 as the longest prefix is not that it is >>>>>>>>> magically >>>>>>>>>>>>>> unnatural. >>>>>>>>>>>>>> Rather, it is that there are a number of current and >>>>>>>>>>>>>>evolving >>>>>>>>>>>> protocols >>>>>>>>>>>>>> that depend upon that /64. The obvious example is that >>>>>>>>>>>>>>SLAAC >>>>>>> does >>>>>>>>>>>> not >>>>>>>>>>>>>> work if subnets are longer than /64. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The rules in this regard are written into approved RFCs. If >>>>>>>>> homenet >>>>>>>>>>>>>> wants to change that, it really needs to go to 6man with a >>>>>>> strong >>>>>>>>>>>> case. >>>>>>>>>>>>>> (for point-to-point inter-router links this was recently >>>>>>>>> relaxed. >>>>>>>>>>>>>> >>>>>>>>>>>>>> At the same time, andy operator who insists on giving homes >>>>>>>>>>>>>>a >>>>>>> /64 >>>>>>>>> is >>>>>>>>>>>>>> being inappropriately restrictive. Homenet should say that, >>>>>>>>> rather >>>>>>>>>>>>>> than >>>>>>>>>>>>>> trying to change the IPv6 architecture. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Yours, >>>>>>>>>>>>>> Joel >>>>>>>>>>>>> Joel, >>>>>>>>>>>>> >>>>>>>>>>>>> I don't consider your email a flame at all. Thanks for >>>>>>> responding. >>>>>>>>>>>>> SLAAC (which I am not at a fan of) won't work but DHCPv6 will >>>>>>>>>>>>> so >>>>>>>>> IMHO >>>>>>>>>>>>> no loss. CGA also won't work but then again I've also never >>>>>>> been a >>>>>>>>>>>>> fan of security half measures. Yes anti-spoofing without >>>>>>>>>>>>>prior >>>>>>>>>>>>> exchange of a key is nice, but no reasonable authorization >>>>>>> could be >>>>>>>>>>>>> based on CGA without also exchanging some sort of key or cert >>>>>>> and >>>>>>>>> at >>>>>>>>>>>>> that point the CGA as a public key is redundant. >>>>>>>>>>>>> >>>>>>>>>>>>> If SLAAC and CGA are the only things that break *and* >>>>>>>>>>>>>providers >>>>>>> do >>>>>>>>>>>>> hand out prefixes that are too small, then /64 prefixes will >>>>>>> have >>>>>>>>> to >>>>>>>>>>>>> be subdivided. >>>>>>>>>>>>> >>>>>>>>>>>>> So a question for you is what else if anything will break? >>>>>>>>>>>>> >>>>>>>>>>>>> I also understand that you are suggesting that this be taken >>>>>>>>>>>>>to >>>>>>>>> 6man. >>>>>>>>>>>>> That is a good suggestion. >>>>>>>>>>>>> >>>>>>>>>>>>> Curtis >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> On 9/22/2012 11:30 PM, Curtis Villamizar wrote: >>>>>>>>>>>>>>> 12. This is sure to be controversial. I pointed out >>>>>>>>>>>>>>>that >>>>>>>>> using >>>>>>>>>>>>>>> subnets longer than /64 is OK as long as they are >>>>>>>>>>>>>>>not >>>>>>>>> leaked >>>>>>>>>>>>>>> into global routing. Please read the text and >>>>>>>>>>>>>>> changes >>>>>>>>>>>> before >>>>>>>>>>>>>>> exploding on this topic. It may be necessary to >>>>>>> subnet a >>>>>>>>>>>> /64 >>>>>>>>>>>>>> if >>>>>>>>>>>>>>> that is all a provider will give you and you need >>>>>>> subnets. >>>>>>>>>>>> It >>>>>>>>>>>>>>> does work and it is no more unnatural than >>>>>>>>>>>>>>> subnetting a >>>>>>>>>>>> class-A >>>>>>>>>>>>>>> network would be in 1990. It means using DHCPv6 and >>>>>>> not >>>>>>>>>>>> using >>>>>>>>>>>>>>> RA prefixes for GUA (otherwise SLAAC implementations >>>>>>> would >>>>>>>>>>>>>>> likely try to use the whole bottom 64). >>>>>>>> _______________________________________________ >>>>>>>> homenet mailing list >>>>>>>> homenet@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/homenet >>>> _______________________________________________ >>>> homenet mailing list >>>> homenet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/homenet >>>> >>> >>> >>> _______________________________________________ >>> homenet mailing list >>> homenet@ietf.org >>> https://www.ietf.org/mailman/listinfo/homenet >> >> >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet > >_______________________________________________ >homenet mailing list >homenet@ietf.org >https://www.ietf.org/mailman/listinfo/homenet From teco@inf-net.nl Tue Sep 25 13:59: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 5C6A221F8816 for ; Tue, 25 Sep 2012 13:59:38 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4xAV-FOLU62B for ; Tue, 25 Sep 2012 13:59:37 -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 6562721F8810 for ; Tue, 25 Sep 2012 13:59:36 -0700 (PDT) Received: by eaak13 with SMTP id k13so956640eaa.31 for ; Tue, 25 Sep 2012 13:59:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=UGRXehqIoQJAoA23kQYhIMr4pVVQp+Xcy1LEbfkRxCc=; b=Z5BA6da7jLKr/jna3aK3vc2w7mq9q/PAvauIjLzoNUvdFYIrvwqWTGbY+SaNIwRI4f XGg/JjGwVcAP1qDzhA9mypUJ1T/qYUD+uaOV2RqpZSSt3mC4lIUBMapTH80y5JL71IXQ +3kXjq6LWGGuqxsdiMJ9KhRwg9NdLFv4ukythc4YnJImeOlkYW5MXGpjm7iizNMt6PrJ jzQFuVb1JWq6ncsscCNh3q4K8IgiMzITYLZKSg1vGupa22R4uqrPCVaeIv4kw0XWoNiP MnNlyAXLOUkQCsZHcsERLQKEDUPiJfQTCWUvpYOnyoulHtcAFVMDIsweVhFIiB8+dmcw OiLg== Received: by 10.14.219.198 with SMTP id m46mr22308650eep.18.1348606775257; Tue, 25 Sep 2012 13:59:35 -0700 (PDT) Received: from ?IPv6:2001:470:7a9b:1:a180:3ec1:42ff:e694? ([2001:470:7a9b:1:a180:3ec1:42ff:e694]) by mx.google.com with ESMTPS id u8sm3906502eel.11.2012.09.25.13.59.33 (version=SSLv3 cipher=OTHER); Tue, 25 Sep 2012 13:59:34 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: Date: Tue, 25 Sep 2012 22:59:32 +0200 Content-Transfer-Encoding: 7bit Message-Id: <0ABFEE76-7737-41B7-96E1-8D90A0EFFC35@inf-net.nl> References: To: Don Sturek X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQny2jfoQFgjXc7UiaYJ7FbXhDkUMQclqp6mqFt+HijdrCMZpj8FedSt9NC8rWeID7dzqmPA Cc: robert.cragie@gridmerge.com, homenet@ietf.org Subject: Re: [homenet] draft-ietf-homenet-arch-04 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 20:59:38 -0000 Op 25 sep. 2012, om 21:55 heeft Don Sturek het volgende geschreven: > Hi Teco, > > The main requirement I see is that a home network with multiple ISP > connections, multiple CERs and a shared subnet must support the ability to > discover services within the entire site (home) despite having devices > with differing ULA prefixes and GUA prefixes. > > How would you see discovery working in such a home network? It might be the right moment to come up with my earlier work on border router discovery. I have to update to incorporate the homenet-arch, and remove details for MANET/Autoconf. Intro & highlights: http://tools.ietf.org/id/draft-boot-brdp-framework-00.txt If there is interest, I'll resubmit for Homenet. Teco > > Don > > > > > On 9/25/12 12:34 PM, "Teco Boot" wrote: > >> Op 25 sep. 2012, om 18:47 heeft Don Sturek het volgende geschreven: >> >> Sorry to jump in. >> >>> Hi Robert, >>> >>> One more point touched on in your note below: >>> 1) Ideally, it would be great if a single authorizatative device >>> existed >>> in the home providing DHCPv6 server services (if supported) and prefix >>> delegation. >> I don't agree. When adding another gateway, to another ISP, I would like >> such to be independent form the existing gear. >> (3.2.2.2. B: Two ISPs, Two CERs, Shared subnet) >> >> >>> One challenge in the description below is having multiple routers on >>> multiple subnets, each possibly acting as a DHCPv6 server within their >>> own >>> subnet and also providing their own ULA prefix. >> When hosts get their addresses for each RA prefix, by using SLAAC and/or >> DHCPv6, what is the challenge? (protocol-wise, not current host behavior) >> >> When hosts get only one GUA, they will use only one link to one ISP (no >> translation). For multi-path, this needs an update. >> >>> >>> We certainly don't want to further confuse address assignment in a >>> setting >>> where IT support does not exist. >> Agreed, we need to improve address assignment. And routing based on >> destination & source addresses. >> >> Teco >> >>> >>> Don >>> >>> >>> >>> >>> On 9/25/12 1:57 AM, "Robert Cragie" wrote: >>> >>>> So let's tweak Curtis' sequence slightly: >>>> >>>> What every host does is: >>>> >>>> if it has no MAC: >>>> pick a random link local address >>>> else >>>> use the MAC to create a link local address >>>> run DAD to make sure no one else has same address >>>> >>>> send a RS >>>> >>>> if it gets RA >>>> use the RA prefix for SLAAC >>>> else >>>> time out and don't bother with SLAAC; can only use link local address >>>> >>>> then hopefully the host also does the following: >>>> >>>> send DHCPv6 client request >>>> >>>> if response >>>> it has yet another address to pick from if it got one using SLAAC >>>> else >>>> time out and get nothing from DHCPv6 >>>> >>>> This should work fine for legacy APs where everything is bridged >>>> underneath it. Where it gets interesting is in the case of cascaded >>>> subnets behind a router connected to an ISP, where one or more of those >>>> subnets may be a mesh network comprised of mesh routers and hosts. I am >>>> not quite sure how ULAs and DHCPv6 would work in this case as there are >>>> limitations as far as I can see (although I accept I probably have a >>>> bit >>>> more reading to do on the subject). >>>> >>>> Robert >>>> >>>> On 25/09/2012 5:45 AM, Curtis Villamizar wrote: >>>>> In message >>>>> Don Sturek writes: >>>>> >>>>>> Hi Curtis, >>>>>> >>>>>> I think the difficulty is each device cannot "use the MAC to create a >>>>>> ULA >>>>>> address". Some authoritative device in the network (eg, the AP) must >>>>>> create the ULA prefix. If a ULA prefix is not present because the AP >>>>>> is a >>>>>> legacy device not capable of providing a ULA prefix, the STA devices >>>>>> must >>>>>> use link locals only. >>>>>> >>>>>> Don >>>>> >>>>> Don, >>>>> >>>>> You are right about there being nothing to generate the ULA prefix in >>>>> your example. My mistake. >>>>> >>>>> But it doesn't change anything. If the AP is a dumb bridge and there >>>>> is no router of any kind, then link local addresses are perfectly >>>>> fine. There is only one subnet in that example, and ULA is not >>>>> needed. That was the example you gave. >>>>> >>>>> Your example had no router just an old AP that acted as a bridge, >>>>> therefore nothing to generate any sort of RA. If there is a router >>>>> and no GUA prefix (which is not your example, but a useful example), >>>>> then ULA can be used. The only RA that is seen is the RA providing a >>>>> ULA prefix which the router can generate. >>>>> >>>>> I did say that the possibility of having to subdivide a /64 only >>>>> exists for GUA. If a router exists which gets a GUA from a provider, >>>>> and there are more subnets than the prefix length can support the two >>>>> options are the ones listed below. (Search for --or--). >>>>> >>>>> Curtis >>>>> >>>>> >>>>>> On 9/24/12 6:52 PM, "Curtis Villamizar" wrote: >>>>>> >>>>>>> In message >>>>>>> Don Sturek writes: >>>>>>> >>>>>>>> Hi Curtis, >>>>>>>> >>>>>>>> I would expect most Wi-Fi AP manufacturers to support the same >>>>>>>> address >>>>>>>> assignment they do today (ie, manual assignment and DHCP). I would >>>>>>>> also expect as more IPv6 deployments happen that SLAAC will also be >>>>>>>> supported (and, yes, even for GUA). >>>>>>>> >>>>>>>> For the types of devices which will be added to Wi-Fi networks in >>>>>>>> the >>>>>>>> future (eg, headless devices like appliances, thermostats, etc.) >>>>>>>> that >>>>>>>> the preferred address assignment will be SLAAC and DHCPv6 (and, >>>>>>>> yes, >>>>>>>> I >>>>>>>> purposely did not remove SLAAC.....) >>>>>>>> >>>>>>>> Don >>>>>>> >>>>>>> Don, >>>>>>> >>>>>>> We seem to be talking past each other so let me again try to be >>>>>>> clear. >>>>>>> >>>>>>> What every host does is: >>>>>>> >>>>>>> if it has no MAC: >>>>>>> pick a random link local (not ULA) address >>>>>>> else >>>>>>> use the MAC to create a ULA address >>>>>>> run DAD to make sure no one else has same address >>>>>>> >>>>>>> send a RS >>>>>>> >>>>>>> if it gets RA >>>>>>> use the RA prefix for SLAAC >>>>>>> else >>>>>>> time out and don't bother with SLAAC >>>>>>> >>>>>>> then hopefully the host also does the following: >>>>>>> >>>>>>> send DHCPv6 client request >>>>>>> >>>>>>> if response >>>>>>> it has yet another address to pick from if it got one using SLAAC >>>>>>> else >>>>>>> time out and get nothing from DHCPv6 >>>>>>> >>>>>>> Note: new extensions to DHCPv6 allow the host to tell DHCPv6 server >>>>>>> the address that it already has (from SLAAC). >>>>>>> >>>>>>> If as in the case of your Wi-Fi with a bridging AP example, there is >>>>>>> no router to give it an DHCPv6 the link local or ULA addresses are >>>>>>> still there and still usable. There is also no router to give it an >>>>>>> RA response so it has no SLAAC assigned address and no DHCPv6 >>>>>>> assigned >>>>>>> address. >>>>>>> >>>>>>> That is the end of your example. >>>>>>> >>>>>>> If there is a router then there is something that can hand out a RA >>>>>>> or >>>>>>> DHCPv6 response. >>>>>>> >>>>>>> In the case were there exists multiple subnets and the CER has been >>>>>>> granted a /64 (or too few /64s to handle the number of subnets), >>>>>>> then: >>>>>>> >>>>>>> it can use RA with /64 on some subnets and give them GUA addresses >>>>>>> and some subnets have no access outside the homenet >>>>>>> >>>>>>> --or-- >>>>>>> >>>>>>> it can not use RA (and therefore prevent SLAAC from being used) and >>>>>>> hand out DHCPv6 addresses and make use of prefixes longer than /64. >>>>>>> This prevents the use of CGA but get connectivity to the entire >>>>>>> homenet. >>>>>>> >>>>>>> If every consumer oriented provider is willing to allocate prefixes >>>>>>> shorter than /64 on request to home users, then the above situation >>>>>>> never occurs. If it does, my argument is that the second option >>>>>>> above >>>>>>> is better than the first. >>>>>>> >>>>>>> Curtis >>>>>>> >>>>>>> >>>>>>>> On 9/24/12 5:11 PM, "Curtis Villamizar" wrote: >>>>>>>> >>>>>>>>> In message <5060BDC7.6020403@freedesktop.org> >>>>>>>>> Jim Gettys writes: >>>>>>>>> >>>>>>>>>> On 09/24/2012 03:17 PM, Don Sturek wrote: >>>>>>>>>>> Hi Curtis, >>>>>>>>>>> >>>>>>>>>>> Here is the use case: >>>>>>>>>>> 1) Customer has a legacy AP in their house >>>>>>>>>>> 2) Customer brings home new devices supporting IPv6 (which are >>>>>>>>>> designed >>>>>>>>>>> to communicate only with other IPv6 based devices in the home) >>>>>>>>>>> 3) The only way these new devices can communicate is through >>>>>>>> address >>>>>>>>>>> assignment using SLAAC and then some discovery method the two >>>>>>>>>>> new >>>>>>>>>> devices >>>>>>>>>>> support (without support from the AP). Here these devices are >>>>>>>>>> assuming >>>>>>>>>>> bridging through the AP...... >>>>>>>>>> >>>>>>>>>> And since current legacy AP's all bridge, we win (even though we >>>>>>>> need to >>>>>>>>>> route in the future). >>>>>>>>> Jim, >>>>>>>>> >>>>>>>>> The point was how do you get local IPv6 within the home with the >>>>>>>>> legacy AP that does only IPv4 and just does bridging of IPv6. >>>>>>>>> First >>>>>>>>> of all you have no subnets. There is no CER to do DHCPv6. >>>>>>>>> >>>>>>>>> In this case you use link local or if everything has a MAC you can >>>>>>>>> use >>>>>>>>> ULA based on the MAC addressses. >>>>>>>>> >>>>>>>>>>> Placing a requirement that every customer who buys a new IPv6 >>>>>>>> device, >>>>>>>>>>> intended to communicate only with other IPv6 devices in the >>>>>>>>>>> home, >>>>>>>> will >>>>>>>>>>> require a forklift upgrade of a deployed network in order to >>>>>>>>>>> work >>>>>>>>>> will not >>>>>>>>>>> be popular. >>>>>>>>>> >>>>>>>>>> Good point. >>>>>>>>> But invalid. The use case Don gave would still work fine. Only >>>>>>>>> GUA >>>>>>>>> addresses are affected. >>>>>>>>> >>>>>>>>>> I loathe DHCP (of any sort) *for basic address assignment, >>>>>>>>>> anyway* >>>>>>>>>> in >>>>>>>>>> the home environment. >>>>>>>>>> >>>>>>>>>> The loathing comes from the exquisite pain of suffering with a >>>>>>>>>> flaky >>>>>>>>>> home network for several months, before realising I had a rogue >>>>>>>>>> DHCP >>>>>>>>>> server somewhere on my network (from wireshark). I then had to >>>>>>>>>> take >>>>>>>> the >>>>>>>>>> mac address, figure out who may have manufactured some device >>>>>>>>>> from >>>>>>>> that >>>>>>>>>> information, and finally figured out the little VOIP ATA adaptor >>>>>>>>>> I >>>>>>>> had >>>>>>>>>> been given liked to do DHCP. >>>>>>>>> It did DHCP on the *WAN side*? You didn't put the rest of your >>>>>>>>> network behind the VOIP box on the LAN side I hope. >>>>>>>>> >>>>>>>>>> This was by far the hardest debugging I've had to do in my home >>>>>>>> network >>>>>>>>>> in normal operation. >>>>>>>>>> >>>>>>>>>> This is well beyond normal home debugging capability of >>>>>>>>>> consumers. >>>>>>>>>> - Jim >>>>>>>>> We all have plenty of crappy IPv4 product horror stories. My VOIP >>>>>>>>> phone locked up now and then and I figured out that if the call >>>>>>>>> lasted >>>>>>>>> longer than the DHCPv4 lease, then it lost the least because it >>>>>>>>> didn't >>>>>>>>> try to renew it. Not only did the call drop, but the device >>>>>>>>> locked >>>>>>>>> up. The first solution was to reboot it now and then. The answer >>>>>>>>> was >>>>>>>>> to configure a fixed address. I was lucky to figure it out before >>>>>>>>> my >>>>>>>>> wife threw the phone through a window. For all I know a later >>>>>>>>> firmware upgrade might have fixed it. VOIP might be more popular >>>>>>>>> if >>>>>>>>> VOIP phones under $600 worked reasonably well. >>>>>>>>> >>>>>>>>> Both nice stories, but both are DHCPv4 related and have nothing at >>>>>>>>> all >>>>>>>>> to do with SLAAC. >>>>>>>>> >>>>>>>>> Curtis >>>>>>>>> >>>>>>>>>>> Don >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 9/24/12 11:49 AM, "Curtis Villamizar" >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> In message >>>>>>>>>>>> Don Sturek writes: >>>>>>>>>>>> >>>>>>>>>>>>> Hi Curtis, >>>>>>>>>>>>> >>>>>>>>>>>>> SLAAC not working is a major problem. >>>>>>>>>>>>> >>>>>>>>>>>>> Don >>>>>>>>>>>> Don, >>>>>>>>>>>> >>>>>>>>>>>> Why? This is an assertion without basis as far as I am >>>>>>>>>>>> concerned. >>>>>>>>>>>> Except CGA there is nothing that breaks without SLAAC. Joel >>>>>>>> brought >>>>>>>>>>>> up ILNP in private email, but I beleive ILNP can also work as >>>>>>>>>>>> the >>>>>>>>>>>> constraints in ILNP are in the ILNP identifier which is not the >>>>>>>> same >>>>>>>>>>>> as the interface address in ILNP for which there is no >>>>>>>>>>>> constraint. >>>>>>>>>>>> >>>>>>>>>>>> I have subnets running fine using a few /112 allocated from >>>>>>>> within a >>>>>>>>>>>> /64 with fixed addresses on rack mount hosts and desktops and >>>>>>>> DHCPv6 >>>>>>>>>>>> for dynamic allocations for laptops. It works fine. Link >>>>>>>>>>>> local >>>>>>>>>>>> addresses are all that is needed to get DHCPv6 to work. No >>>>>>>>>>>> host >>>>>>>> ever >>>>>>>>>>>> receives a RA since my routers won't give them one, so no host >>>>>>>> ever >>>>>>>>>>>> tries to generate an address using SLAAC. The only constraint >>>>>>>>>>>> is >>>>>>>>>> that >>>>>>>>>>>> any host connecting to my Ethernet or wireless must run a DHCP >>>>>>>> client >>>>>>>>>>>> and if they want an IPv6 GUA must run a DHCPv6 client. DHCPv4 >>>>>>>>>>>> and >>>>>>>>>>>> DHCPv6 servers are available in every subnet except one GbE >>>>>>>> subnet in >>>>>>>>>>>> the rack and to a few hosts in my home office. >>>>>>>>>>>> >>>>>>>>>>>> So as far as I am concerned we have an assertion that no SLAAC >>>>>>>>>>>> is >>>>>>>> a >>>>>>>>>>>> problem and existance proof that it is not. Beside CGA and >>>>>>>> requiring >>>>>>>>>>>> that hosts run DHCPv6 if they want an IPv6 GUA, what can I not >>>>>>>>>> support >>>>>>>>>>>> on these /112 subnets? >>>>>>>>>>>> >>>>>>>>>>>> Curtis >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> On 9/23/12 4:09 PM, "Curtis Villamizar" >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> In message <505E83F6.3030900@joelhalpern.com> >>>>>>>>>>>>>> "Joel M. Halpern" writes: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Since you invited flames... >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The argument on /64 as the longest prefix is not that it is >>>>>>>>>> magically >>>>>>>>>>>>>>> unnatural. >>>>>>>>>>>>>>> Rather, it is that there are a number of current and >>>>>>>>>>>>>>> evolving >>>>>>>>>>>>> protocols >>>>>>>>>>>>>>> that depend upon that /64. The obvious example is that >>>>>>>>>>>>>>> SLAAC >>>>>>>> does >>>>>>>>>>>>> not >>>>>>>>>>>>>>> work if subnets are longer than /64. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The rules in this regard are written into approved RFCs. If >>>>>>>>>> homenet >>>>>>>>>>>>>>> wants to change that, it really needs to go to 6man with a >>>>>>>> strong >>>>>>>>>>>>> case. >>>>>>>>>>>>>>> (for point-to-point inter-router links this was recently >>>>>>>>>> relaxed. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> At the same time, andy operator who insists on giving homes >>>>>>>>>>>>>>> a >>>>>>>> /64 >>>>>>>>>> is >>>>>>>>>>>>>>> being inappropriately restrictive. Homenet should say that, >>>>>>>>>> rather >>>>>>>>>>>>>>> than >>>>>>>>>>>>>>> trying to change the IPv6 architecture. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yours, >>>>>>>>>>>>>>> Joel >>>>>>>>>>>>>> Joel, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I don't consider your email a flame at all. Thanks for >>>>>>>> responding. >>>>>>>>>>>>>> SLAAC (which I am not at a fan of) won't work but DHCPv6 will >>>>>>>>>>>>>> so >>>>>>>>>> IMHO >>>>>>>>>>>>>> no loss. CGA also won't work but then again I've also never >>>>>>>> been a >>>>>>>>>>>>>> fan of security half measures. Yes anti-spoofing without >>>>>>>>>>>>>> prior >>>>>>>>>>>>>> exchange of a key is nice, but no reasonable authorization >>>>>>>> could be >>>>>>>>>>>>>> based on CGA without also exchanging some sort of key or cert >>>>>>>> and >>>>>>>>>> at >>>>>>>>>>>>>> that point the CGA as a public key is redundant. >>>>>>>>>>>>>> >>>>>>>>>>>>>> If SLAAC and CGA are the only things that break *and* >>>>>>>>>>>>>> providers >>>>>>>> do >>>>>>>>>>>>>> hand out prefixes that are too small, then /64 prefixes will >>>>>>>> have >>>>>>>>>> to >>>>>>>>>>>>>> be subdivided. >>>>>>>>>>>>>> >>>>>>>>>>>>>> So a question for you is what else if anything will break? >>>>>>>>>>>>>> >>>>>>>>>>>>>> I also understand that you are suggesting that this be taken >>>>>>>>>>>>>> to >>>>>>>>>> 6man. >>>>>>>>>>>>>> That is a good suggestion. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Curtis >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 9/22/2012 11:30 PM, Curtis Villamizar wrote: >>>>>>>>>>>>>>>> 12. This is sure to be controversial. I pointed out >>>>>>>>>>>>>>>> that >>>>>>>>>> using >>>>>>>>>>>>>>>> subnets longer than /64 is OK as long as they are >>>>>>>>>>>>>>>> not >>>>>>>>>> leaked >>>>>>>>>>>>>>>> into global routing. Please read the text and >>>>>>>>>>>>>>>> changes >>>>>>>>>>>>> before >>>>>>>>>>>>>>>> exploding on this topic. It may be necessary to >>>>>>>> subnet a >>>>>>>>>>>>> /64 >>>>>>>>>>>>>>> if >>>>>>>>>>>>>>>> that is all a provider will give you and you need >>>>>>>> subnets. >>>>>>>>>>>>> It >>>>>>>>>>>>>>>> does work and it is no more unnatural than >>>>>>>>>>>>>>>> subnetting a >>>>>>>>>>>>> class-A >>>>>>>>>>>>>>>> network would be in 1990. It means using DHCPv6 and >>>>>>>> not >>>>>>>>>>>>> using >>>>>>>>>>>>>>>> RA prefixes for GUA (otherwise SLAAC implementations >>>>>>>> would >>>>>>>>>>>>>>>> likely try to use the whole bottom 64). >>>>>>>>> _______________________________________________ >>>>>>>>> homenet mailing list >>>>>>>>> homenet@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/homenet >>>>> _______________________________________________ >>>>> homenet mailing list >>>>> homenet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/homenet >>>>> >>>> >>>> >>>> _______________________________________________ >>>> homenet mailing list >>>> homenet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/homenet >>> >>> >>> _______________________________________________ >>> homenet mailing list >>> homenet@ietf.org >>> https://www.ietf.org/mailman/listinfo/homenet >> >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet > > From rja.lists@gmail.com Wed Sep 26 07:23: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 A826521F882D for ; Wed, 26 Sep 2012 07:23:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.569 X-Spam-Level: X-Spam-Status: No, score=-3.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, 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 g6IfVoxNa-pc for ; Wed, 26 Sep 2012 07:23:54 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 24C5621F879D for ; Wed, 26 Sep 2012 07:23:54 -0700 (PDT) Received: by qcac10 with SMTP id c10so590772qca.31 for ; Wed, 26 Sep 2012 07:23:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=dk0hPZUKmpRCxm64v0rczu0ce2/Ck4Ucg98p3qXkDfU=; b=G/FBrpnr1vXOgUnpl9CT66FPWzdiCJibiYHUvpSG+QiqWyxqCSQs+9tvubVs3pnCCX yLGm0mhHNPopphFQ1kQ0vXDv2RZAqJYFsZf5eXGSrAikmsdVxiDLnqgp8ScNAiKUzdEh Aj723IikMHkg7YvnC0KIDMEmB5IwjOaaXO+BBh8wEQskEqy2ZV/rwQVJOqj6ROzYH7if KPLVraBh9b6EhD6R6a145Pggy/qnVNCbPcXZVTXI2NMR4EKyCUWoSz7HeRcQEPHNo1/Q 06aNV6oFbHfaG4r6Ri5aVaoiNkZL5fi88TvSA9OZOsFAlvpOrAUvTV6WoicCRSXGZSUF UYJg== Received: by 10.229.136.135 with SMTP id r7mr451259qct.75.1348669433543; Wed, 26 Sep 2012 07:23:53 -0700 (PDT) Received: from [10.30.20.14] (pool-74-110-100-136.nrflva.fios.verizon.net. [74.110.100.136]) by mx.google.com with ESMTPS id h8sm4906848qap.16.2012.09.26.07.23.52 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 26 Sep 2012 07:23:52 -0700 (PDT) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 26 Sep 2012 10:23:51 -0400 Message-Id: <490BC468-0C4E-48F0-9A1B-BD3F84580534@gmail.com> To: homenet@ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: Re: [homenet] draft-ietf-homenet-arch-04 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 14:23:54 -0000 On Saturday, 22 September 2012, Joel M Halpern wrote: > The argument on /64 as the longest prefix is not that it is > magically unnatural. Rather, it is that there are a number of > current and evolving protocols that depend upon that /64. > The obvious example is that SLAAC does not work if subnets > are longer than /64. > > The rules in this regard are written into approved RFCs. > If homenet wants to change that, it really needs to go to 6man > with a strong case. (for point-to-point inter-router links > this was recently relaxed. > > At the same time, andy operator who insists on giving homes > a /64 is being inappropriately restrictive. Homenet should > say that, rather than trying to change the IPv6 architecture. > > Yours, > Joel +1 to all of the above. Please particularly note that SLAAC is especially likely to be deployed in home environments, much more likely than any other alternative (e.g. DHCPv6). Several widely deployed consumer electronic devices ONLY support IPv6 via SLAAC, and won't work with DHCPv6 (at present). So breaking SLAAC is VERY bad operationally in a home deployment at present, and for the foreseeable future. Yours, Ran Atkinson From rja.lists@gmail.com Wed Sep 26 07:35: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 03C6321F86F4 for ; Wed, 26 Sep 2012 07:35:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.572 X-Spam-Level: X-Spam-Status: No, score=-3.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, 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 RbsdsYW2dlHH for ; Wed, 26 Sep 2012 07:35:35 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2BCFF21F86E5 for ; Wed, 26 Sep 2012 07:35:35 -0700 (PDT) Received: by qcac10 with SMTP id c10so603465qca.31 for ; Wed, 26 Sep 2012 07:35:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=WoJyjDWArF9MLc4TyCboZofO5220Islo4wHrujXONEA=; b=OJYhBdSP2LXsj07ijb8vWjpHC9fAg7e5ujU4nvSaR5VwG2VU38B75YSmJ1PkuIVLZl AHd6hBSR+HuTGOQSes1Pn5CwW1CpT3h6XI3MKg7tdUs8+KfUqZBREWIIKBfMERYPoK3Z 3C1DsGDFqM6MPEQ3fldo+ks9nFcvlv5AygZdkVm6balb10BhL6/9O8QI2lBHteZvPKge ZkIyPeNYewWVfsyYg91b8cvVTUSic38WgO/Xy8STpJl71GXj9JW/Dolmn+bnkSRMn1E3 qyHZcP7e83/p2GBqtL0Keqm52v9k3ZBNct+6dj24gNsUjAfjyLE0lrB/2O5L0Y+hxJhT oFrw== Received: by 10.224.193.69 with SMTP id dt5mr2582865qab.2.1348670134703; Wed, 26 Sep 2012 07:35:34 -0700 (PDT) Received: from [10.30.20.14] (pool-74-110-100-136.nrflva.fios.verizon.net. [74.110.100.136]) by mx.google.com with ESMTPS id gx8sm4940180qab.12.2012.09.26.07.35.32 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 26 Sep 2012 07:35:34 -0700 (PDT) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 26 Sep 2012 10:35:31 -0400 Message-Id: <5C56BF52-CB1B-44DE-B2A4-8EB3517B2C37@gmail.com> To: homenet@ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [homenet] Border Router Discovery Protocol 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, 26 Sep 2012 14:35:36 -0000 On Tuesday, 25 September 2012, Teco Boot wrote: > It might be the right moment to come up with my earlier work > on border router discovery. I have to update to incorporate > the homenet-arch, and remove details for MANET/Autoconf. > > Intro & highlights: > http://tools.ietf.org/id/draft-boot-brdp-framework-00.txt > > If there is interest, I'll resubmit for Homenet. > > Teco Yes, please. Please don't remove the details for MANET/AutoConf, but perhaps put those details into their own section(s). The operational reality is that the IETF needs more tools for automatic configuration, zero or minimal configuration, site resilience in the face of upstream link changes, and also site renumbering. A well designed tool for border router discovery ought to work well in MANET environments, AutoConf environments, ZeroConf environments, HomeNet environments, and probably also for renumbering events. I think BRDP is very close to what is needed. I would not want to lose generality of solution merely because it is being discussed in one particular IETF WG at the moment. Cheers, Ran PS: I'd also be quite happy to see BRDP go out as an Experimental status RFC initially, whether through the IETF track, IRTF Routing RG, or the ISE-track. BRDP seems very useful and useful protocols tend to self-deploy into environments where they are useful. From wassim.haddad@ericsson.com Wed Sep 26 10:25: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 0E83321F85AE for ; Wed, 26 Sep 2012 10:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 fDqPANs+QJiM for ; Wed, 26 Sep 2012 10:25:33 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id D3CD321F85BB for ; Wed, 26 Sep 2012 10:25:32 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q8QHVZ5R013159 for ; Wed, 26 Sep 2012 12:31:50 -0500 Received: from [155.53.121.73] (147.117.20.214) by eusaamw0707.eamcs.ericsson.se (147.117.20.92) with Microsoft SMTP Server id 8.3.264.1; Wed, 26 Sep 2012 13:25:21 -0400 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Apple Message framework v1278) From: Wassim Haddad Date: Wed, 26 Sep 2012 10:26:27 -0700 Content-Transfer-Encoding: quoted-printable Message-ID: <08880DCF-FEC8-4B52-8DB4-0300AC1EC811@ericsson.com> References: <20120925175537.27212.40311.idtracker@ietfa.amsl.com> To: "homenet@ietf.org Group" X-Mailer: Apple Mail (2.1278) Cc: Wassim Haddad Subject: [homenet] Fwd: I-D Action: draft-haddad-homenet-multihomed-00 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, 26 Sep 2012 17:25:34 -0000 Dear all, We have submitted a problem statement for multihoming in homenet. Comments appreciated! =20 Regards, Wassim H. Begin forwarded message: > From: "internet-drafts@ietf.org" > Subject: I-D Action: draft-haddad-homenet-multihomed-00.txt > Date: September 25, 2012 10:55:38 AM PDT > To: "i-d-announce@ietf.org" > Reply-To: "internet-drafts@ietf.org" >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : Multihoming in Homenet > Author(s) : Wassim Haddad > Damien Saucez > Joel Halpern > Filename : draft-haddad-homenet-multihomed-00.txt > Pages : 7 > Date : 2012-09-25 >=20 > Abstract: > So far, multihoming in Homenet must be supported by the hosts as > there is no mean to use simultaneously the different Internet = Service > Providers of the "Homenet" without risking flow disruption. In this > memo, we describe the problem statement for multihoming in Homenet. > We also propose a high level solution that answers this particular > problem. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-haddad-homenet-multihomed >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-haddad-homenet-multihomed-00 From mcr@sandelman.ca Sun Sep 30 12:24:58 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC4921F84BF for ; Sun, 30 Sep 2012 12:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.034 X-Spam-Level: X-Spam-Status: No, score=-1.034 tagged_above=-999 required=5 tests=[AWL=-1.494, BAYES_40=-0.185, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] 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 kAhLacSydG43 for ; Sun, 30 Sep 2012 12:24:55 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 69B2121F84B6 for ; Sun, 30 Sep 2012 12:24:55 -0700 (PDT) Received: from sandelman.ca (wlan196.sandelman.ca [209.87.252.196]) by relay.sandelman.ca (Postfix) with ESMTPS id 182D781AA for ; Sun, 30 Sep 2012 15:18:15 -0400 (EDT) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id DEB77CA0BC for ; Sun, 30 Sep 2012 15:24:53 -0400 (EDT) To: homenet@ietf.org From: Michael Richardson X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Sun, 30 Sep 2012 15:24:53 -0400 Message-ID: <5516.1349033093@sandelman.ca> Sender: mcr@sandelman.ca Subject: [homenet] homenet naming -- securing DHCP channel 9.4 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, 30 Sep 2012 19:24:58 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable I am reading mglt-homenet-naming-delegation-00. (hmm. It was on my reading list, maybe it got superseded, or adopted alread= y?) Section 9.4 articulates that the DHCP channel between the CPE and the ISP DHCP server MUST be secured. I certainly agree with the concern, but=20 1) I think that the opportunity for attack is perhaps understated. Given that homenet envisions plugging things together in arbitrary ways, it seems that it would be quite easy for an attacker to confuse a CPE into thinking that it is in fact the CPE closest to the ISP, when in fact it isn't.=20=20 =20=20 2) yet, I think that the consequences of "failing secure" might be undiresable. Given that homenet envisions plugging things together in arbitrary ways, if a CPE makes a security boundary mis-classification, it may view it's "WAN" link as being on the outside rather than on the inside. It might then attempt to secure the DHCP channel to the (non-existant ISP), and fail, resulting in... packets not flowing. 3) I think that section 9.4 confuses reasons why the CPE should be concerned if another CPE can impersonate it, reasons why the ISP should be concerned if one CPE can impersonate it, and reasons why the CPE should be concerned if another entity can impersonate the ISP. I think that most of the concerns are solved by PPPoE connections that use CHAP. In the cable-modem-stuff-looks-like-ethernet scenario,=20 unless there is some strong controls on what MAC address is where, it will, as the section suggests, fall to DHCP security. =2D-=20 Michael Richardson =2Don the road- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAABAgAGBQJQaJxhAAoJEKD0KQ7Gj3P2ZRoIALdqFCxTRW7bbhOkX1J4tt/9 tOsEbl0iZIol//9cTLbtmSJR0fr1VeNU+VeMNZKkN0jmbP25uDFmBE7OwRGEv9/n zIVAnZCMolU8zl9IVCjudc1XeS8XKPJxZJf6DfsQMWQZV+E1qaZURp1VXZMYmO+X G8krRKy9B5SevZapOG9YcRuZmN1YonmYm11ofKFilsrqVi4cx3e/NgPJdycMHPDq J/wUID3yMstEUucLs/7lr5lt5cJyR1vLSK2C16WRIHgMPJ2wwrtB8nIjt0IsKoaf hZT9DzmJWkJotZGPMbFkvDAJSDM2d1yik+ogcOLFeIVBQ5btUnofaIRyM/FGfQ4= =Nf/7 -----END PGP SIGNATURE----- --=-=-=-- From curtis@occnc.com Sun Sep 30 12:48:43 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3128621F84D6 for ; Sun, 30 Sep 2012 12:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.558 X-Spam-Level: X-Spam-Status: No, score=-1.558 tagged_above=-999 required=5 tests=[AWL=-0.817, BAYES_20=-0.74, 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 JHZPnU1BSTtl for ; Sun, 30 Sep 2012 12:48:42 -0700 (PDT) Received: from gateway1.orleans.occnc.com (gateway1.orleans.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id EE7EC21F84A1 for ; Sun, 30 Sep 2012 12:48:24 -0700 (PDT) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id q8UJmFLN026481; Sun, 30 Sep 2012 15:48:15 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201209301948.q8UJmFLN026481@gateway1.orleans.occnc.com> To: Brian E Carpenter From: Curtis Villamizar In-reply-to: Your message of "Tue, 25 Sep 2012 14:35:30 BST." <5061B322.1080805@gmail.com> Date: Sun, 30 Sep 2012 15:48:15 -0400 Cc: homenet@ietf.org, "Joel M. Halpern" , Don Sturek , Jim Gettys , curtis@occnc.com Subject: Re: [homenet] draft-ietf-homenet-arch-04 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, 30 Sep 2012 19:48:43 -0000 In message <5061B322.1080805@gmail.com> Brian E Carpenter writes: > On 25/09/2012 02:01, Don Sturek wrote: > > Hi Curtis, > > > > I would expect most Wi-Fi AP manufacturers to support the same address > > assignment they do today (ie, manual assignment and DHCP). I would also > > expect as more IPv6 deployments happen that SLAAC will also be supported > > (and, yes, even for GUA). > > It MUST be supported according to RFC 6204 and 6204bis (and of course > by all hosts, according to RFC 6434). > > Brian Brian, The "I would expect" wording is due to the very long lag between RFC mandates and the consumer products on retailer shelves that support those RFCs. Consumer products have yet to catch up to the RFCs in the 2xxx and 3xxx RFC range let alone anything in the 6xxx range. For example, the 4 port GbE and 2 Wifi channel AP I recently bought to run cerowrt supported little more than bridging IPv6 with the vendor firmware yet is advertised as having IPv6 support. That is not even the low end of consumer products. Curtis > > For the types of devices which will be added to Wi-Fi networks in the > > future (eg, headless devices like appliances, thermostats, etc.) that the > > preferred address assignment will be SLAAC and DHCPv6 (and, yes, I > > purposely did not remove SLAAC.....) > > > > Don > > > > > > > > On 9/24/12 5:11 PM, "Curtis Villamizar" wrote: > > > >> In message <5060BDC7.6020403@freedesktop.org> > >> Jim Gettys writes: > >> > >>> On 09/24/2012 03:17 PM, Don Sturek wrote: > >>>> Hi Curtis, > >>>> > >>>> Here is the use case: > >>>> 1) Customer has a legacy AP in their house > >>>> 2) Customer brings home new devices supporting IPv6 (which are > >>> designed > >>>> to communicate only with other IPv6 based devices in the home) > >>>> 3) The only way these new devices can communicate is through address > >>>> assignment using SLAAC and then some discovery method the two new > >>> devices > >>>> support (without support from the AP). Here these devices are > >>> assuming > >>>> bridging through the AP...... > >>> > >>> And since current legacy AP's all bridge, we win (even though we need to > >>> route in the future). > >> Jim, > >> > >> The point was how do you get local IPv6 within the home with the > >> legacy AP that does only IPv4 and just does bridging of IPv6. First > >> of all you have no subnets. There is no CER to do DHCPv6. > >> > >> In this case you use link local or if everything has a MAC you can use > >> ULA based on the MAC addressses. > >> > >>>> Placing a requirement that every customer who buys a new IPv6 device, > >>>> intended to communicate only with other IPv6 devices in the home, will > >>>> require a forklift upgrade of a deployed network in order to work > >>> will not > >>>> be popular. > >>> > >>> Good point. > >> But invalid. The use case Don gave would still work fine. Only GUA > >> addresses are affected. > >> > >>> I loathe DHCP (of any sort) *for basic address assignment, anyway* in > >>> the home environment. > >>> > >>> The loathing comes from the exquisite pain of suffering with a flaky > >>> home network for several months, before realising I had a rogue DHCP > >>> server somewhere on my network (from wireshark). I then had to take the > >>> mac address, figure out who may have manufactured some device from that > >>> information, and finally figured out the little VOIP ATA adaptor I had > >>> been given liked to do DHCP. > >> It did DHCP on the *WAN side*? You didn't put the rest of your > >> network behind the VOIP box on the LAN side I hope. > >> > >>> This was by far the hardest debugging I've had to do in my home network > >>> in normal operation. > >>> > >>> This is well beyond normal home debugging capability of consumers. > >>> - Jim > >> We all have plenty of crappy IPv4 product horror stories. My VOIP > >> phone locked up now and then and I figured out that if the call lasted > >> longer than the DHCPv4 lease, then it lost the least because it didn't > >> try to renew it. Not only did the call drop, but the device locked > >> up. The first solution was to reboot it now and then. The answer was > >> to configure a fixed address. I was lucky to figure it out before my > >> wife threw the phone through a window. For all I know a later > >> firmware upgrade might have fixed it. VOIP might be more popular if > >> VOIP phones under $600 worked reasonably well. > >> > >> Both nice stories, but both are DHCPv4 related and have nothing at all > >> to do with SLAAC. > >> > >> Curtis > >> > >>>> Don > >>>> > >>>> > >>>> > >>>> > >>>> On 9/24/12 11:49 AM, "Curtis Villamizar" wrote: > >>>> > >>>>> In message > >>>>> Don Sturek writes: > >>>>> > >>>>>> Hi Curtis, > >>>>>> > >>>>>> SLAAC not working is a major problem. > >>>>>> > >>>>>> Don > >>>>> Don, > >>>>> > >>>>> Why? This is an assertion without basis as far as I am concerned. > >>>>> Except CGA there is nothing that breaks without SLAAC. Joel brought > >>>>> up ILNP in private email, but I beleive ILNP can also work as the > >>>>> constraints in ILNP are in the ILNP identifier which is not the same > >>>>> as the interface address in ILNP for which there is no constraint. > >>>>> > >>>>> I have subnets running fine using a few /112 allocated from within a > >>>>> /64 with fixed addresses on rack mount hosts and desktops and DHCPv6 > >>>>> for dynamic allocations for laptops. It works fine. Link local > >>>>> addresses are all that is needed to get DHCPv6 to work. No host ever > >>>>> receives a RA since my routers won't give them one, so no host ever > >>>>> tries to generate an address using SLAAC. The only constraint is > >>> that > >>>>> any host connecting to my Ethernet or wireless must run a DHCP client > >>>>> and if they want an IPv6 GUA must run a DHCPv6 client. DHCPv4 and > >>>>> DHCPv6 servers are available in every subnet except one GbE subnet in > >>>>> the rack and to a few hosts in my home office. > >>>>> > >>>>> So as far as I am concerned we have an assertion that no SLAAC is a > >>>>> problem and existance proof that it is not. Beside CGA and requiring > >>>>> that hosts run DHCPv6 if they want an IPv6 GUA, what can I not > >>> support > >>>>> on these /112 subnets? > >>>>> > >>>>> Curtis > >>>>> > >>>>> > >>>>>> On 9/23/12 4:09 PM, "Curtis Villamizar" wrote: > >>>>>> > >>>>>>> In message <505E83F6.3030900@joelhalpern.com> > >>>>>>> "Joel M. Halpern" writes: > >>>>>>> > >>>>>>>> Since you invited flames... > >>>>>>>> > >>>>>>>> The argument on /64 as the longest prefix is not that it is > >>> magically > >>>>>>>> unnatural. > >>>>>>>> Rather, it is that there are a number of current and evolving > >>>>>> protocols > >>>>>>>> that depend upon that /64. The obvious example is that SLAAC does > >>>>>> not > >>>>>>>> work if subnets are longer than /64. > >>>>>>>> > >>>>>>>> The rules in this regard are written into approved RFCs. If > >>> homenet > >>>>>>>> wants to change that, it really needs to go to 6man with a strong > >>>>>> case. > >>>>>>>> (for point-to-point inter-router links this was recently > >>> relaxed. > >>>>>>>> > >>>>>>>> At the same time, andy operator who insists on giving homes a /64 > >>> is > >>>>>>>> being inappropriately restrictive. Homenet should say that, > >>> rather > >>>>>>>> than > >>>>>>>> trying to change the IPv6 architecture. > >>>>>>>> > >>>>>>>> Yours, > >>>>>>>> Joel > >>>>>>> Joel, > >>>>>>> > >>>>>>> I don't consider your email a flame at all. Thanks for responding. > >>>>>>> > >>>>>>> SLAAC (which I am not at a fan of) won't work but DHCPv6 will so > >>> IMHO > >>>>>>> no loss. CGA also won't work but then again I've also never been a > >>>>>>> fan of security half measures. Yes anti-spoofing without prior > >>>>>>> exchange of a key is nice, but no reasonable authorization could be > >>>>>>> based on CGA without also exchanging some sort of key or cert and > >>> at > >>>>>>> that point the CGA as a public key is redundant. > >>>>>>> > >>>>>>> If SLAAC and CGA are the only things that break *and* providers do > >>>>>>> hand out prefixes that are too small, then /64 prefixes will have > >>> to > >>>>>>> be subdivided. > >>>>>>> > >>>>>>> So a question for you is what else if anything will break? > >>>>>>> > >>>>>>> I also understand that you are suggesting that this be taken to > >>> 6man. > >>>>>>> That is a good suggestion. > >>>>>>> > >>>>>>> Curtis > >>>>>>> > >>>>>>> > >>>>>>>> On 9/22/2012 11:30 PM, Curtis Villamizar wrote: > >>>>>>>>> 12. This is sure to be controversial. I pointed out that > >>> using > >>>>>>>>> subnets longer than /64 is OK as long as they are not > >>> leaked > >>>>>>>>> into global routing. Please read the text and changes > >>>>>> before > >>>>>>>>> exploding on this topic. It may be necessary to subnet a > >>>>>> /64 > >>>>>>>> if > >>>>>>>>> that is all a provider will give you and you need subnets. > >>>>>> It > >>>>>>>>> does work and it is no more unnatural than subnetting a > >>>>>> class-A > >>>>>>>>> network would be in 1990. It means using DHCPv6 and not > >>>>>> using > >>>>>>>>> RA prefixes for GUA (otherwise SLAAC implementations would > >>>>>>>>> likely try to use the whole bottom 64). > >> _______________________________________________ > >> homenet mailing list > >> homenet@ietf.org > >> https://www.ietf.org/mailman/listinfo/homenet > > > > > > _______________________________________________ > > homenet mailing list > > homenet@ietf.org > > https://www.ietf.org/mailman/listinfo/homenet From curtis@occnc.com Sun Sep 30 15: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 8BA1821F84B6 for ; Sun, 30 Sep 2012 15:37:00 -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.151, 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 4rH0fv-PNwgc for ; Sun, 30 Sep 2012 15:36:59 -0700 (PDT) Received: from gateway1.orleans.occnc.com (gateway1.orleans.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id A183321F846C for ; Sun, 30 Sep 2012 15:36:58 -0700 (PDT) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id q8UMalVW027432; Sun, 30 Sep 2012 18:36:47 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201209302236.q8UMalVW027432@gateway1.orleans.occnc.com> To: Don Sturek From: Curtis Villamizar In-reply-to: Your message of "Tue, 25 Sep 2012 09:47:22 PDT." Date: Sun, 30 Sep 2012 18:36:47 -0400 Cc: robert.cragie@gridmerge.com, homenet@ietf.org Subject: Re: [homenet] draft-ietf-homenet-arch-04 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, 30 Sep 2012 22:37:00 -0000 In message Don Sturek writes: > Hi Robert, > > One more point touched on in your note below: > 1) Ideally, it would be great if a single authorizatative device existed > in the home providing DHCPv6 server services (if supported) and prefix > delegation. > > One challenge in the description below is having multiple routers on > multiple subnets, each possibly acting as a DHCPv6 server within their own > subnet and also providing their own ULA prefix. > > We certainly don't want to further confuse address assignment in a setting > where IT support does not exist. > > Don We want things to "just work" witb no config. Link local on each subnet and a routing protocol works for any topology. ULA just allows summarization of subnets in the routing protocol, such that host routes are not needed (though not a big deal if host routes are used in a homenet). This would "just work" when using link local or ULA. How to subdivide a GUA prefix among the subnets is another issue. In principle, though I know of no proposals to do this yet, the set of GUA that are available from one of more routers with a provider link could be coordinated via the routing protocol (for example, using a new OSPF Opaque LSA). Curtis > On 9/25/12 1:57 AM, "Robert Cragie" wrote: > > >So let's tweak Curtis' sequence slightly: > > > >What every host does is: > > > > if it has no MAC: > > pick a random link local address > > else > > use the MAC to create a link local address > > run DAD to make sure no one else has same address > > > > send a RS > > > > if it gets RA > > use the RA prefix for SLAAC > > else > > time out and don't bother with SLAAC; can only use link local address > > > >then hopefully the host also does the following: > > > > send DHCPv6 client request > > > > if response > > it has yet another address to pick from if it got one using SLAAC > > else > > time out and get nothing from DHCPv6 > > > >This should work fine for legacy APs where everything is bridged > >underneath it. Where it gets interesting is in the case of cascaded > >subnets behind a router connected to an ISP, where one or more of those > >subnets may be a mesh network comprised of mesh routers and hosts. I am > >not quite sure how ULAs and DHCPv6 would work in this case as there are > >limitations as far as I can see (although I accept I probably have a bit > >more reading to do on the subject). > > > >Robert > > > >On 25/09/2012 5:45 AM, Curtis Villamizar wrote: > >> In message > >> Don Sturek writes: > >> > >>> Hi Curtis, > >>> > >>> I think the difficulty is each device cannot "use the MAC to create a > >>>ULA > >>> address". Some authoritative device in the network (eg, the AP) must > >>> create the ULA prefix. If a ULA prefix is not present because the AP > >>>is a > >>> legacy device not capable of providing a ULA prefix, the STA devices > >>>must > >>> use link locals only. > >>> > >>> Don > >> > >> Don, > >> > >> You are right about there being nothing to generate the ULA prefix in > >> your example. My mistake. > >> > >> But it doesn't change anything. If the AP is a dumb bridge and there > >> is no router of any kind, then link local addresses are perfectly > >> fine. There is only one subnet in that example, and ULA is not > >> needed. That was the example you gave. > >> > >> Your example had no router just an old AP that acted as a bridge, > >> therefore nothing to generate any sort of RA. If there is a router > >> and no GUA prefix (which is not your example, but a useful example), > >> then ULA can be used. The only RA that is seen is the RA providing a > >> ULA prefix which the router can generate. > >> > >> I did say that the possibility of having to subdivide a /64 only > >> exists for GUA. If a router exists which gets a GUA from a provider, > >> and there are more subnets than the prefix length can support the two > >> options are the ones listed below. (Search for --or--). > >> > >> Curtis > >> > >> > >>> On 9/24/12 6:52 PM, "Curtis Villamizar" wrote: > >>> > >>>> In message > >>>> Don Sturek writes: > >>>> > >>>>> Hi Curtis, > >>>>> > >>>>> I would expect most Wi-Fi AP manufacturers to support the same > >>>>>address > >>>>> assignment they do today (ie, manual assignment and DHCP). I would > >>>>> also expect as more IPv6 deployments happen that SLAAC will also be > >>>>> supported (and, yes, even for GUA). > >>>>> > >>>>> For the types of devices which will be added to Wi-Fi networks in the > >>>>> future (eg, headless devices like appliances, thermostats, etc.) that > >>>>> the preferred address assignment will be SLAAC and DHCPv6 (and, yes, > >>>>>I > >>>>> purposely did not remove SLAAC.....) > >>>>> > >>>>> Don > >>>> > >>>> Don, > >>>> > >>>> We seem to be talking past each other so let me again try to be clear. > >>>> > >>>> What every host does is: > >>>> > >>>> if it has no MAC: > >>>> pick a random link local (not ULA) address > >>>> else > >>>> use the MAC to create a ULA address > >>>> run DAD to make sure no one else has same address > >>>> > >>>> send a RS > >>>> > >>>> if it gets RA > >>>> use the RA prefix for SLAAC > >>>> else > >>>> time out and don't bother with SLAAC > >>>> > >>>> then hopefully the host also does the following: > >>>> > >>>> send DHCPv6 client request > >>>> > >>>> if response > >>>> it has yet another address to pick from if it got one using SLAAC > >>>> else > >>>> time out and get nothing from DHCPv6 > >>>> > >>>> Note: new extensions to DHCPv6 allow the host to tell DHCPv6 server > >>>> the address that it already has (from SLAAC). > >>>> > >>>> If as in the case of your Wi-Fi with a bridging AP example, there is > >>>> no router to give it an DHCPv6 the link local or ULA addresses are > >>>> still there and still usable. There is also no router to give it an > >>>> RA response so it has no SLAAC assigned address and no DHCPv6 assigned > >>>> address. > >>>> > >>>> That is the end of your example. > >>>> > >>>> If there is a router then there is something that can hand out a RA or > >>>> DHCPv6 response. > >>>> > >>>> In the case were there exists multiple subnets and the CER has been > >>>> granted a /64 (or too few /64s to handle the number of subnets), then: > >>>> > >>>> it can use RA with /64 on some subnets and give them GUA addresses > >>>> and some subnets have no access outside the homenet > >>>> > >>>> --or-- > >>>> > >>>> it can not use RA (and therefore prevent SLAAC from being used) and > >>>> hand out DHCPv6 addresses and make use of prefixes longer than /64. > >>>> This prevents the use of CGA but get connectivity to the entire > >>>> homenet. > >>>> > >>>> If every consumer oriented provider is willing to allocate prefixes > >>>> shorter than /64 on request to home users, then the above situation > >>>> never occurs. If it does, my argument is that the second option above > >>>> is better than the first. > >>>> > >>>> Curtis > >>>> > >>>> > >>>>> On 9/24/12 5:11 PM, "Curtis Villamizar" wrote: > >>>>> > >>>>>> In message <5060BDC7.6020403@freedesktop.org> > >>>>>> Jim Gettys writes: > >>>>>> > >>>>>>> On 09/24/2012 03:17 PM, Don Sturek wrote: > >>>>>>>> Hi Curtis, > >>>>>>>> > >>>>>>>> Here is the use case: > >>>>>>>> 1) Customer has a legacy AP in their house > >>>>>>>> 2) Customer brings home new devices supporting IPv6 (which are > >>>>>>> designed > >>>>>>>> to communicate only with other IPv6 based devices in the home) > >>>>>>>> 3) The only way these new devices can communicate is through > >>>>> address > >>>>>>>> assignment using SLAAC and then some discovery method the two new > >>>>>>> devices > >>>>>>>> support (without support from the AP). Here these devices are > >>>>>>> assuming > >>>>>>>> bridging through the AP...... > >>>>>>> > >>>>>>> And since current legacy AP's all bridge, we win (even though we > >>>>> need to > >>>>>>> route in the future). > >>>>>> Jim, > >>>>>> > >>>>>> The point was how do you get local IPv6 within the home with the > >>>>>> legacy AP that does only IPv4 and just does bridging of IPv6. First > >>>>>> of all you have no subnets. There is no CER to do DHCPv6. > >>>>>> > >>>>>> In this case you use link local or if everything has a MAC you can > >>>>>>use > >>>>>> ULA based on the MAC addressses. > >>>>>> > >>>>>>>> Placing a requirement that every customer who buys a new IPv6 > >>>>> device, > >>>>>>>> intended to communicate only with other IPv6 devices in the home, > >>>>> will > >>>>>>>> require a forklift upgrade of a deployed network in order to work > >>>>>>> will not > >>>>>>>> be popular. > >>>>>>> > >>>>>>> Good point. > >>>>>> But invalid. The use case Don gave would still work fine. Only GUA > >>>>>> addresses are affected. > >>>>>> > >>>>>>> I loathe DHCP (of any sort) *for basic address assignment, anyway* > >>>>>>>in > >>>>>>> the home environment. > >>>>>>> > >>>>>>> The loathing comes from the exquisite pain of suffering with a > >>>>>>>flaky > >>>>>>> home network for several months, before realising I had a rogue > >>>>>>>DHCP > >>>>>>> server somewhere on my network (from wireshark). I then had to > >>>>>>>take > >>>>> the > >>>>>>> mac address, figure out who may have manufactured some device from > >>>>> that > >>>>>>> information, and finally figured out the little VOIP ATA adaptor I > >>>>> had > >>>>>>> been given liked to do DHCP. > >>>>>> It did DHCP on the *WAN side*? You didn't put the rest of your > >>>>>> network behind the VOIP box on the LAN side I hope. > >>>>>> > >>>>>>> This was by far the hardest debugging I've had to do in my home > >>>>> network > >>>>>>> in normal operation. > >>>>>>> > >>>>>>> This is well beyond normal home debugging capability of consumers. > >>>>>>> - Jim > >>>>>> We all have plenty of crappy IPv4 product horror stories. My VOIP > >>>>>> phone locked up now and then and I figured out that if the call > >>>>>>lasted > >>>>>> longer than the DHCPv4 lease, then it lost the least because it > >>>>>>didn't > >>>>>> try to renew it. Not only did the call drop, but the device locked > >>>>>> up. The first solution was to reboot it now and then. The answer > >>>>>>was > >>>>>> to configure a fixed address. I was lucky to figure it out before > >>>>>>my > >>>>>> wife threw the phone through a window. For all I know a later > >>>>>> firmware upgrade might have fixed it. VOIP might be more popular if > >>>>>> VOIP phones under $600 worked reasonably well. > >>>>>> > >>>>>> Both nice stories, but both are DHCPv4 related and have nothing at > >>>>>>all > >>>>>> to do with SLAAC. > >>>>>> > >>>>>> Curtis > >>>>>> > >>>>>>>> Don > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> On 9/24/12 11:49 AM, "Curtis Villamizar" wrote: > >>>>>>>> > >>>>>>>>> In message > >>>>>>>>> Don Sturek writes: > >>>>>>>>> > >>>>>>>>>> Hi Curtis, > >>>>>>>>>> > >>>>>>>>>> SLAAC not working is a major problem. > >>>>>>>>>> > >>>>>>>>>> Don > >>>>>>>>> Don, > >>>>>>>>> > >>>>>>>>> Why? This is an assertion without basis as far as I am > >>>>>>>>>concerned. > >>>>>>>>> Except CGA there is nothing that breaks without SLAAC. Joel > >>>>> brought > >>>>>>>>> up ILNP in private email, but I beleive ILNP can also work as the > >>>>>>>>> constraints in ILNP are in the ILNP identifier which is not the > >>>>> same > >>>>>>>>> as the interface address in ILNP for which there is no > >>>>>>>>>constraint. > >>>>>>>>> > >>>>>>>>> I have subnets running fine using a few /112 allocated from > >>>>> within a > >>>>>>>>> /64 with fixed addresses on rack mount hosts and desktops and > >>>>> DHCPv6 > >>>>>>>>> for dynamic allocations for laptops. It works fine. Link local > >>>>>>>>> addresses are all that is needed to get DHCPv6 to work. No host > >>>>> ever > >>>>>>>>> receives a RA since my routers won't give them one, so no host > >>>>> ever > >>>>>>>>> tries to generate an address using SLAAC. The only constraint is > >>>>>>> that > >>>>>>>>> any host connecting to my Ethernet or wireless must run a DHCP > >>>>> client > >>>>>>>>> and if they want an IPv6 GUA must run a DHCPv6 client. DHCPv4 > >>>>>>>>>and > >>>>>>>>> DHCPv6 servers are available in every subnet except one GbE > >>>>> subnet in > >>>>>>>>> the rack and to a few hosts in my home office. > >>>>>>>>> > >>>>>>>>> So as far as I am concerned we have an assertion that no SLAAC is > >>>>> a > >>>>>>>>> problem and existance proof that it is not. Beside CGA and > >>>>> requiring > >>>>>>>>> that hosts run DHCPv6 if they want an IPv6 GUA, what can I not > >>>>>>> support > >>>>>>>>> on these /112 subnets? > >>>>>>>>> > >>>>>>>>> Curtis > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> On 9/23/12 4:09 PM, "Curtis Villamizar" > >>>>>>>>>>wrote: > >>>>>>>>>> > >>>>>>>>>>> In message <505E83F6.3030900@joelhalpern.com> > >>>>>>>>>>> "Joel M. Halpern" writes: > >>>>>>>>>>> > >>>>>>>>>>>> Since you invited flames... > >>>>>>>>>>>> > >>>>>>>>>>>> The argument on /64 as the longest prefix is not that it is > >>>>>>> magically > >>>>>>>>>>>> unnatural. > >>>>>>>>>>>> Rather, it is that there are a number of current and evolving > >>>>>>>>>> protocols > >>>>>>>>>>>> that depend upon that /64. The obvious example is that SLAAC > >>>>> does > >>>>>>>>>> not > >>>>>>>>>>>> work if subnets are longer than /64. > >>>>>>>>>>>> > >>>>>>>>>>>> The rules in this regard are written into approved RFCs. If > >>>>>>> homenet > >>>>>>>>>>>> wants to change that, it really needs to go to 6man with a > >>>>> strong > >>>>>>>>>> case. > >>>>>>>>>>>> (for point-to-point inter-router links this was recently > >>>>>>> relaxed. > >>>>>>>>>>>> > >>>>>>>>>>>> At the same time, andy operator who insists on giving homes a > >>>>> /64 > >>>>>>> is > >>>>>>>>>>>> being inappropriately restrictive. Homenet should say that, > >>>>>>> rather > >>>>>>>>>>>> than > >>>>>>>>>>>> trying to change the IPv6 architecture. > >>>>>>>>>>>> > >>>>>>>>>>>> Yours, > >>>>>>>>>>>> Joel > >>>>>>>>>>> Joel, > >>>>>>>>>>> > >>>>>>>>>>> I don't consider your email a flame at all. Thanks for > >>>>> responding. > >>>>>>>>>>> SLAAC (which I am not at a fan of) won't work but DHCPv6 will > >>>>>>>>>>>so > >>>>>>> IMHO > >>>>>>>>>>> no loss. CGA also won't work but then again I've also never > >>>>> been a > >>>>>>>>>>> fan of security half measures. Yes anti-spoofing without prior > >>>>>>>>>>> exchange of a key is nice, but no reasonable authorization > >>>>> could be > >>>>>>>>>>> based on CGA without also exchanging some sort of key or cert > >>>>> and > >>>>>>> at > >>>>>>>>>>> that point the CGA as a public key is redundant. > >>>>>>>>>>> > >>>>>>>>>>> If SLAAC and CGA are the only things that break *and* providers > >>>>> do > >>>>>>>>>>> hand out prefixes that are too small, then /64 prefixes will > >>>>> have > >>>>>>> to > >>>>>>>>>>> be subdivided. > >>>>>>>>>>> > >>>>>>>>>>> So a question for you is what else if anything will break? > >>>>>>>>>>> > >>>>>>>>>>> I also understand that you are suggesting that this be taken to > >>>>>>> 6man. > >>>>>>>>>>> That is a good suggestion. > >>>>>>>>>>> > >>>>>>>>>>> Curtis > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> On 9/22/2012 11:30 PM, Curtis Villamizar wrote: > >>>>>>>>>>>>> 12. This is sure to be controversial. I pointed out that > >>>>>>> using > >>>>>>>>>>>>> subnets longer than /64 is OK as long as they are not > >>>>>>> leaked > >>>>>>>>>>>>> into global routing. Please read the text and > >>>>>>>>>>>>>changes > >>>>>>>>>> before > >>>>>>>>>>>>> exploding on this topic. It may be necessary to > >>>>> subnet a > >>>>>>>>>> /64 > >>>>>>>>>>>> if > >>>>>>>>>>>>> that is all a provider will give you and you need > >>>>> subnets. > >>>>>>>>>> It > >>>>>>>>>>>>> does work and it is no more unnatural than > >>>>>>>>>>>>>subnetting a > >>>>>>>>>> class-A > >>>>>>>>>>>>> network would be in 1990. It means using DHCPv6 and > >>>>> not > >>>>>>>>>> using > >>>>>>>>>>>>> RA prefixes for GUA (otherwise SLAAC implementations > >>>>> would > >>>>>>>>>>>>> likely try to use the whole bottom 64). > >>>>>> _______________________________________________ > >>>>>> homenet mailing list > >>>>>> homenet@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/homenet > >> _______________________________________________ > >> homenet mailing list > >> homenet@ietf.org > >> https://www.ietf.org/mailman/listinfo/homenet > >> > > > > > >_______________________________________________ > >homenet mailing list > >homenet@ietf.org > >https://www.ietf.org/mailman/listinfo/homenet > > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > From curtis@occnc.com Sun Sep 30 16:03: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 202B421F84F5 for ; Sun, 30 Sep 2012 16:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.456 X-Spam-Level: X-Spam-Status: No, score=-2.456 tagged_above=-999 required=5 tests=[AWL=0.144, 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 yFA8r4dREprB for ; Sun, 30 Sep 2012 16:03:01 -0700 (PDT) Received: from gateway1.orleans.occnc.com (gateway1.orleans.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 29CFD21F84F3 for ; Sun, 30 Sep 2012 16:03:00 -0700 (PDT) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id q8UN2o0T027602; Sun, 30 Sep 2012 19:02:50 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201209302302.q8UN2o0T027602@gateway1.orleans.occnc.com> To: Teco Boot From: Curtis Villamizar In-reply-to: Your message of "Tue, 25 Sep 2012 22:59:32 +0200." <0ABFEE76-7737-41B7-96E1-8D90A0EFFC35@inf-net.nl> Date: Sun, 30 Sep 2012 19:02:50 -0400 Cc: robert.cragie@gridmerge.com, homenet@ietf.org, Don Sturek Subject: Re: [homenet] draft-ietf-homenet-arch-04 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, 30 Sep 2012 23:03:03 -0000 In message <0ABFEE76-7737-41B7-96E1-8D90A0EFFC35@inf-net.nl> Teco Boot writes: > > Op 25 sep. 2012, om 21:55 heeft Don Sturek het volgende geschreven: > > > Hi Teco, > > > > The main requirement I see is that a home network with multiple ISP > > connections, multiple CERs and a shared subnet must support the ability to > > discover services within the entire site (home) despite having devices > > with differing ULA prefixes and GUA prefixes. > > > > How would you see discovery working in such a home network? > > It might be the right moment to come up with my earlier work on border > router discovery. I have to update to incorporate the homenet-arch, and > remove details for MANET/Autoconf. Intro & highlights: > http://tools.ietf.org/id/draft-boot-brdp-framework-00.txt > > If there is interest, I'll resubmit for Homenet. > > Teco Just looked at that draft. It solves one of the problems, having more than one GUA prefix. It does not solve another closely related problem, having more than one subnet behind the CER or border routers (BR101 and BR201 in your diagram) where there is no prior configuration. In your "Figure 2: Scenario 2" all routers have the same set of addresses on each of their interfaces. This is not generally how subnets are laid out. Each interface on a router gets a different link local address. The /48 is usually split into a set of /64, one per subnet. In a managed network (enterprise, clueful soho, etc) the split of a /48 into 16 or less /64s today is done by configuration (configuration of prefixes on the routers or DHCP server and relays). Curtis > > Don > > > > > > > > > > On 9/25/12 12:34 PM, "Teco Boot" wrote: > > > >> Op 25 sep. 2012, om 18:47 heeft Don Sturek het volgende geschreven: > >> > >> Sorry to jump in. > >> > >>> Hi Robert, > >>> > >>> One more point touched on in your note below: > >>> 1) Ideally, it would be great if a single authorizatative device > >>> existed > >>> in the home providing DHCPv6 server services (if supported) and prefix > >>> delegation. > >> I don't agree. When adding another gateway, to another ISP, I would like > >> such to be independent form the existing gear. > >> (3.2.2.2. B: Two ISPs, Two CERs, Shared subnet) > >> > >> > >>> One challenge in the description below is having multiple routers on > >>> multiple subnets, each possibly acting as a DHCPv6 server within their > >>> own > >>> subnet and also providing their own ULA prefix. > >> When hosts get their addresses for each RA prefix, by using SLAAC and/or > >> DHCPv6, what is the challenge? (protocol-wise, not current host behavior) > >> > >> When hosts get only one GUA, they will use only one link to one ISP (no > >> translation). For multi-path, this needs an update. > >> > >>> > >>> We certainly don't want to further confuse address assignment in a > >>> setting > >>> where IT support does not exist. > >> Agreed, we need to improve address assignment. And routing based on > >> destination & source addresses. > >> > >> Teco > >> > >>> > >>> Don > >>> > >>> > >>> > >>> > >>> On 9/25/12 1:57 AM, "Robert Cragie" wrote: > >>> > >>>> So let's tweak Curtis' sequence slightly: > >>>> > >>>> What every host does is: > >>>> > >>>> if it has no MAC: > >>>> pick a random link local address > >>>> else > >>>> use the MAC to create a link local address > >>>> run DAD to make sure no one else has same address > >>>> > >>>> send a RS > >>>> > >>>> if it gets RA > >>>> use the RA prefix for SLAAC > >>>> else > >>>> time out and don't bother with SLAAC; can only use link local address > >>>> > >>>> then hopefully the host also does the following: > >>>> > >>>> send DHCPv6 client request > >>>> > >>>> if response > >>>> it has yet another address to pick from if it got one using SLAAC > >>>> else > >>>> time out and get nothing from DHCPv6 > >>>> > >>>> This should work fine for legacy APs where everything is bridged > >>>> underneath it. Where it gets interesting is in the case of cascaded > >>>> subnets behind a router connected to an ISP, where one or more of those > >>>> subnets may be a mesh network comprised of mesh routers and hosts. I am > >>>> not quite sure how ULAs and DHCPv6 would work in this case as there are > >>>> limitations as far as I can see (although I accept I probably have a > >>>> bit > >>>> more reading to do on the subject). > >>>> > >>>> Robert > >>>> > >>>> On 25/09/2012 5:45 AM, Curtis Villamizar wrote: > >>>>> In message > >>>>> Don Sturek writes: > >>>>> > >>>>>> Hi Curtis, > >>>>>> > >>>>>> I think the difficulty is each device cannot "use the MAC to create a > >>>>>> ULA > >>>>>> address". Some authoritative device in the network (eg, the AP) must > >>>>>> create the ULA prefix. If a ULA prefix is not present because the AP > >>>>>> is a > >>>>>> legacy device not capable of providing a ULA prefix, the STA devices > >>>>>> must > >>>>>> use link locals only. > >>>>>> > >>>>>> Don > >>>>> > >>>>> Don, > >>>>> > >>>>> You are right about there being nothing to generate the ULA prefix in > >>>>> your example. My mistake. > >>>>> > >>>>> But it doesn't change anything. If the AP is a dumb bridge and there > >>>>> is no router of any kind, then link local addresses are perfectly > >>>>> fine. There is only one subnet in that example, and ULA is not > >>>>> needed. That was the example you gave. > >>>>> > >>>>> Your example had no router just an old AP that acted as a bridge, > >>>>> therefore nothing to generate any sort of RA. If there is a router > >>>>> and no GUA prefix (which is not your example, but a useful example), > >>>>> then ULA can be used. The only RA that is seen is the RA providing a > >>>>> ULA prefix which the router can generate. > >>>>> > >>>>> I did say that the possibility of having to subdivide a /64 only > >>>>> exists for GUA. If a router exists which gets a GUA from a provider, > >>>>> and there are more subnets than the prefix length can support the two > >>>>> options are the ones listed below. (Search for --or--). > >>>>> > >>>>> Curtis > >>>>> > >>>>> > >>>>>> On 9/24/12 6:52 PM, "Curtis Villamizar" wrote: > >>>>>> > >>>>>>> In message > >>>>>>> Don Sturek writes: > >>>>>>> > >>>>>>>> Hi Curtis, > >>>>>>>> > >>>>>>>> I would expect most Wi-Fi AP manufacturers to support the same > >>>>>>>> address > >>>>>>>> assignment they do today (ie, manual assignment and DHCP). I would > >>>>>>>> also expect as more IPv6 deployments happen that SLAAC will also be > >>>>>>>> supported (and, yes, even for GUA). > >>>>>>>> > >>>>>>>> For the types of devices which will be added to Wi-Fi networks in > >>>>>>>> the > >>>>>>>> future (eg, headless devices like appliances, thermostats, etc.) > >>>>>>>> that > >>>>>>>> the preferred address assignment will be SLAAC and DHCPv6 (and, > >>>>>>>> yes, > >>>>>>>> I > >>>>>>>> purposely did not remove SLAAC.....) > >>>>>>>> > >>>>>>>> Don > >>>>>>> > >>>>>>> Don, > >>>>>>> > >>>>>>> We seem to be talking past each other so let me again try to be > >>>>>>> clear. > >>>>>>> > >>>>>>> What every host does is: > >>>>>>> > >>>>>>> if it has no MAC: > >>>>>>> pick a random link local (not ULA) address > >>>>>>> else > >>>>>>> use the MAC to create a ULA address > >>>>>>> run DAD to make sure no one else has same address > >>>>>>> > >>>>>>> send a RS > >>>>>>> > >>>>>>> if it gets RA > >>>>>>> use the RA prefix for SLAAC > >>>>>>> else > >>>>>>> time out and don't bother with SLAAC > >>>>>>> > >>>>>>> then hopefully the host also does the following: > >>>>>>> > >>>>>>> send DHCPv6 client request > >>>>>>> > >>>>>>> if response > >>>>>>> it has yet another address to pick from if it got one using SLAAC > >>>>>>> else > >>>>>>> time out and get nothing from DHCPv6 > >>>>>>> > >>>>>>> Note: new extensions to DHCPv6 allow the host to tell DHCPv6 server > >>>>>>> the address that it already has (from SLAAC). > >>>>>>> > >>>>>>> If as in the case of your Wi-Fi with a bridging AP example, there is > >>>>>>> no router to give it an DHCPv6 the link local or ULA addresses are > >>>>>>> still there and still usable. There is also no router to give it an > >>>>>>> RA response so it has no SLAAC assigned address and no DHCPv6 > >>>>>>> assigned > >>>>>>> address. > >>>>>>> > >>>>>>> That is the end of your example. > >>>>>>> > >>>>>>> If there is a router then there is something that can hand out a RA > >>>>>>> or > >>>>>>> DHCPv6 response. > >>>>>>> > >>>>>>> In the case were there exists multiple subnets and the CER has been > >>>>>>> granted a /64 (or too few /64s to handle the number of subnets), > >>>>>>> then: > >>>>>>> > >>>>>>> it can use RA with /64 on some subnets and give them GUA addresses > >>>>>>> and some subnets have no access outside the homenet > >>>>>>> > >>>>>>> --or-- > >>>>>>> > >>>>>>> it can not use RA (and therefore prevent SLAAC from being used) and > >>>>>>> hand out DHCPv6 addresses and make use of prefixes longer than /64. > >>>>>>> This prevents the use of CGA but get connectivity to the entire > >>>>>>> homenet. > >>>>>>> > >>>>>>> If every consumer oriented provider is willing to allocate prefixes > >>>>>>> shorter than /64 on request to home users, then the above situation > >>>>>>> never occurs. If it does, my argument is that the second option > >>>>>>> above > >>>>>>> is better than the first. > >>>>>>> > >>>>>>> Curtis > >>>>>>> > >>>>>>> > >>>>>>>> On 9/24/12 5:11 PM, "Curtis Villamizar" wrote: > >>>>>>>> > >>>>>>>>> In message <5060BDC7.6020403@freedesktop.org> > >>>>>>>>> Jim Gettys writes: > >>>>>>>>> > >>>>>>>>>> On 09/24/2012 03:17 PM, Don Sturek wrote: > >>>>>>>>>>> Hi Curtis, > >>>>>>>>>>> > >>>>>>>>>>> Here is the use case: > >>>>>>>>>>> 1) Customer has a legacy AP in their house > >>>>>>>>>>> 2) Customer brings home new devices supporting IPv6 (which are > >>>>>>>>>> designed > >>>>>>>>>>> to communicate only with other IPv6 based devices in the home) > >>>>>>>>>>> 3) The only way these new devices can communicate is through > >>>>>>>> address > >>>>>>>>>>> assignment using SLAAC and then some discovery method the two > >>>>>>>>>>> new > >>>>>>>>>> devices > >>>>>>>>>>> support (without support from the AP). Here these devices are > >>>>>>>>>> assuming > >>>>>>>>>>> bridging through the AP...... > >>>>>>>>>> > >>>>>>>>>> And since current legacy AP's all bridge, we win (even though we > >>>>>>>> need to > >>>>>>>>>> route in the future). > >>>>>>>>> Jim, > >>>>>>>>> > >>>>>>>>> The point was how do you get local IPv6 within the home with the > >>>>>>>>> legacy AP that does only IPv4 and just does bridging of IPv6. > >>>>>>>>> First > >>>>>>>>> of all you have no subnets. There is no CER to do DHCPv6. > >>>>>>>>> > >>>>>>>>> In this case you use link local or if everything has a MAC you can > >>>>>>>>> use > >>>>>>>>> ULA based on the MAC addressses. > >>>>>>>>> > >>>>>>>>>>> Placing a requirement that every customer who buys a new IPv6 > >>>>>>>> device, > >>>>>>>>>>> intended to communicate only with other IPv6 devices in the > >>>>>>>>>>> home, > >>>>>>>> will > >>>>>>>>>>> require a forklift upgrade of a deployed network in order to > >>>>>>>>>>> work > >>>>>>>>>> will not > >>>>>>>>>>> be popular. > >>>>>>>>>> > >>>>>>>>>> Good point. > >>>>>>>>> But invalid. The use case Don gave would still work fine. Only > >>>>>>>>> GUA > >>>>>>>>> addresses are affected. > >>>>>>>>> > >>>>>>>>>> I loathe DHCP (of any sort) *for basic address assignment, > >>>>>>>>>> anyway* > >>>>>>>>>> in > >>>>>>>>>> the home environment. > >>>>>>>>>> > >>>>>>>>>> The loathing comes from the exquisite pain of suffering with a > >>>>>>>>>> flaky > >>>>>>>>>> home network for several months, before realising I had a rogue > >>>>>>>>>> DHCP > >>>>>>>>>> server somewhere on my network (from wireshark). I then had to > >>>>>>>>>> take > >>>>>>>> the > >>>>>>>>>> mac address, figure out who may have manufactured some device > >>>>>>>>>> from > >>>>>>>> that > >>>>>>>>>> information, and finally figured out the little VOIP ATA adaptor > >>>>>>>>>> I > >>>>>>>> had > >>>>>>>>>> been given liked to do DHCP. > >>>>>>>>> It did DHCP on the *WAN side*? You didn't put the rest of your > >>>>>>>>> network behind the VOIP box on the LAN side I hope. > >>>>>>>>> > >>>>>>>>>> This was by far the hardest debugging I've had to do in my home > >>>>>>>> network > >>>>>>>>>> in normal operation. > >>>>>>>>>> > >>>>>>>>>> This is well beyond normal home debugging capability of > >>>>>>>>>> consumers. > >>>>>>>>>> - Jim > >>>>>>>>> We all have plenty of crappy IPv4 product horror stories. My VOIP > >>>>>>>>> phone locked up now and then and I figured out that if the call > >>>>>>>>> lasted > >>>>>>>>> longer than the DHCPv4 lease, then it lost the least because it > >>>>>>>>> didn't > >>>>>>>>> try to renew it. Not only did the call drop, but the device > >>>>>>>>> locked > >>>>>>>>> up. The first solution was to reboot it now and then. The answer > >>>>>>>>> was > >>>>>>>>> to configure a fixed address. I was lucky to figure it out before > >>>>>>>>> my > >>>>>>>>> wife threw the phone through a window. For all I know a later > >>>>>>>>> firmware upgrade might have fixed it. VOIP might be more popular > >>>>>>>>> if > >>>>>>>>> VOIP phones under $600 worked reasonably well. > >>>>>>>>> > >>>>>>>>> Both nice stories, but both are DHCPv4 related and have nothing at > >>>>>>>>> all > >>>>>>>>> to do with SLAAC. > >>>>>>>>> > >>>>>>>>> Curtis > >>>>>>>>> > >>>>>>>>>>> Don > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> On 9/24/12 11:49 AM, "Curtis Villamizar" > >>>>>>>>>>> wrote: > >>>>>>>>>>> > >>>>>>>>>>>> In message > >>>>>>>>>>>> Don Sturek writes: > >>>>>>>>>>>> > >>>>>>>>>>>>> Hi Curtis, > >>>>>>>>>>>>> > >>>>>>>>>>>>> SLAAC not working is a major problem. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Don > >>>>>>>>>>>> Don, > >>>>>>>>>>>> > >>>>>>>>>>>> Why? This is an assertion without basis as far as I am > >>>>>>>>>>>> concerned. > >>>>>>>>>>>> Except CGA there is nothing that breaks without SLAAC. Joel > >>>>>>>> brought > >>>>>>>>>>>> up ILNP in private email, but I beleive ILNP can also work as > >>>>>>>>>>>> the > >>>>>>>>>>>> constraints in ILNP are in the ILNP identifier which is not the > >>>>>>>> same > >>>>>>>>>>>> as the interface address in ILNP for which there is no > >>>>>>>>>>>> constraint. > >>>>>>>>>>>> > >>>>>>>>>>>> I have subnets running fine using a few /112 allocated from > >>>>>>>> within a > >>>>>>>>>>>> /64 with fixed addresses on rack mount hosts and desktops and > >>>>>>>> DHCPv6 > >>>>>>>>>>>> for dynamic allocations for laptops. It works fine. Link > >>>>>>>>>>>> local > >>>>>>>>>>>> addresses are all that is needed to get DHCPv6 to work. No > >>>>>>>>>>>> host > >>>>>>>> ever > >>>>>>>>>>>> receives a RA since my routers won't give them one, so no host > >>>>>>>> ever > >>>>>>>>>>>> tries to generate an address using SLAAC. The only constraint > >>>>>>>>>>>> is > >>>>>>>>>> that > >>>>>>>>>>>> any host connecting to my Ethernet or wireless must run a DHCP > >>>>>>>> client > >>>>>>>>>>>> and if they want an IPv6 GUA must run a DHCPv6 client. DHCPv4 > >>>>>>>>>>>> and > >>>>>>>>>>>> DHCPv6 servers are available in every subnet except one GbE > >>>>>>>> subnet in > >>>>>>>>>>>> the rack and to a few hosts in my home office. > >>>>>>>>>>>> > >>>>>>>>>>>> So as far as I am concerned we have an assertion that no SLAAC > >>>>>>>>>>>> is > >>>>>>>> a > >>>>>>>>>>>> problem and existance proof that it is not. Beside CGA and > >>>>>>>> requiring > >>>>>>>>>>>> that hosts run DHCPv6 if they want an IPv6 GUA, what can I not > >>>>>>>>>> support > >>>>>>>>>>>> on these /112 subnets? > >>>>>>>>>>>> > >>>>>>>>>>>> Curtis > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> On 9/23/12 4:09 PM, "Curtis Villamizar" > >>>>>>>>>>>>> wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>>> In message <505E83F6.3030900@joelhalpern.com> > >>>>>>>>>>>>>> "Joel M. Halpern" writes: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Since you invited flames... > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> The argument on /64 as the longest prefix is not that it is > >>>>>>>>>> magically > >>>>>>>>>>>>>>> unnatural. > >>>>>>>>>>>>>>> Rather, it is that there are a number of current and > >>>>>>>>>>>>>>> evolving > >>>>>>>>>>>>> protocols > >>>>>>>>>>>>>>> that depend upon that /64. The obvious example is that > >>>>>>>>>>>>>>> SLAAC > >>>>>>>> does > >>>>>>>>>>>>> not > >>>>>>>>>>>>>>> work if subnets are longer than /64. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> The rules in this regard are written into approved RFCs. If > >>>>>>>>>> homenet > >>>>>>>>>>>>>>> wants to change that, it really needs to go to 6man with a > >>>>>>>> strong > >>>>>>>>>>>>> case. > >>>>>>>>>>>>>>> (for point-to-point inter-router links this was recently > >>>>>>>>>> relaxed. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> At the same time, andy operator who insists on giving homes > >>>>>>>>>>>>>>> a > >>>>>>>> /64 > >>>>>>>>>> is > >>>>>>>>>>>>>>> being inappropriately restrictive. Homenet should say that, > >>>>>>>>>> rather > >>>>>>>>>>>>>>> than > >>>>>>>>>>>>>>> trying to change the IPv6 architecture. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Yours, > >>>>>>>>>>>>>>> Joel > >>>>>>>>>>>>>> Joel, > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> I don't consider your email a flame at all. Thanks for > >>>>>>>> responding. > >>>>>>>>>>>>>> SLAAC (which I am not at a fan of) won't work but DHCPv6 will > >>>>>>>>>>>>>> so > >>>>>>>>>> IMHO > >>>>>>>>>>>>>> no loss. CGA also won't work but then again I've also never > >>>>>>>> been a > >>>>>>>>>>>>>> fan of security half measures. Yes anti-spoofing without > >>>>>>>>>>>>>> prior > >>>>>>>>>>>>>> exchange of a key is nice, but no reasonable authorization > >>>>>>>> could be > >>>>>>>>>>>>>> based on CGA without also exchanging some sort of key or cert > >>>>>>>> and > >>>>>>>>>> at > >>>>>>>>>>>>>> that point the CGA as a public key is redundant. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> If SLAAC and CGA are the only things that break *and* > >>>>>>>>>>>>>> providers > >>>>>>>> do > >>>>>>>>>>>>>> hand out prefixes that are too small, then /64 prefixes will > >>>>>>>> have > >>>>>>>>>> to > >>>>>>>>>>>>>> be subdivided. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> So a question for you is what else if anything will break? > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> I also understand that you are suggesting that this be taken > >>>>>>>>>>>>>> to > >>>>>>>>>> 6man. > >>>>>>>>>>>>>> That is a good suggestion. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Curtis > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> On 9/22/2012 11:30 PM, Curtis Villamizar wrote: > >>>>>>>>>>>>>>>> 12. This is sure to be controversial. I pointed out > >>>>>>>>>>>>>>>> that > >>>>>>>>>> using > >>>>>>>>>>>>>>>> subnets longer than /64 is OK as long as they are > >>>>>>>>>>>>>>>> not > >>>>>>>>>> leaked > >>>>>>>>>>>>>>>> into global routing. Please read the text and > >>>>>>>>>>>>>>>> changes > >>>>>>>>>>>>> before > >>>>>>>>>>>>>>>> exploding on this topic. It may be necessary to > >>>>>>>> subnet a > >>>>>>>>>>>>> /64 > >>>>>>>>>>>>>>> if > >>>>>>>>>>>>>>>> that is all a provider will give you and you need > >>>>>>>> subnets. > >>>>>>>>>>>>> It > >>>>>>>>>>>>>>>> does work and it is no more unnatural than > >>>>>>>>>>>>>>>> subnetting a > >>>>>>>>>>>>> class-A > >>>>>>>>>>>>>>>> network would be in 1990. It means using DHCPv6 and > >>>>>>>> not > >>>>>>>>>>>>> using > >>>>>>>>>>>>>>>> RA prefixes for GUA (otherwise SLAAC implementations > >>>>>>>> would > >>>>>>>>>>>>>>>> likely try to use the whole bottom 64). From curtis@occnc.com Sun Sep 30 16:33: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 5900221F849A for ; Sun, 30 Sep 2012 16:33:28 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWwjdNC9qFau for ; Sun, 30 Sep 2012 16:33:27 -0700 (PDT) Received: from gateway1.orleans.occnc.com (gateway1.orleans.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 9ABB921F8480 for ; Sun, 30 Sep 2012 16:33:27 -0700 (PDT) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id q8UNXOR7029594; Sun, 30 Sep 2012 19:33:24 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201209302333.q8UNXOR7029594@gateway1.orleans.occnc.com> To: RJ Atkinson From: Curtis Villamizar In-reply-to: Your message of "Wed, 26 Sep 2012 10:23:51 EDT." <490BC468-0C4E-48F0-9A1B-BD3F84580534@gmail.com> Date: Sun, 30 Sep 2012 19:33:24 -0400 Cc: homenet@ietf.org Subject: Re: [homenet] draft-ietf-homenet-arch-04 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, 30 Sep 2012 23:33:28 -0000 In message <490BC468-0C4E-48F0-9A1B-BD3F84580534@gmail.com> RJ Atkinson writes: > On Saturday, 22 September 2012, Joel M Halpern wrote: > > The argument on /64 as the longest prefix is not that it is > > magically unnatural. Rather, it is that there are a number of > > current and evolving protocols that depend upon that /64. > > The obvious example is that SLAAC does not work if subnets > > are longer than /64. > > > > The rules in this regard are written into approved RFCs. > > If homenet wants to change that, it really needs to go to 6man > > with a strong case. (for point-to-point inter-router links > > this was recently relaxed. > > > > At the same time, andy operator who insists on giving homes > > a /64 is being inappropriately restrictive. Homenet should > > say that, rather than trying to change the IPv6 architecture. > > > > Yours, > > Joel > > +1 to all of the above. > > Please particularly note that SLAAC is especially likely > to be deployed in home environments, much more likely than > any other alternative (e.g. DHCPv6). Several widely deployed > consumer electronic devices ONLY support IPv6 via SLAAC, > and won't work with DHCPv6 (at present). So breaking SLAAC > is VERY bad operationally in a home deployment at present, > and for the foreseeable future. > > Yours, > > Ran Atkinson Ran, Breaking SLAAC is bad. Consumer oriented providers handing out /64s to homenets is also bad. But if a homenet does get nothing more than a /64 and multiple subnets are needed, then SLAAC gets broken. Curtis PS- Please reply to this part off list: What "widely deployed consumer electronic devices" do you have in mind? Any chance of firmware upgrade or is the firmware too thoroughly baked in? Note that just about anything running android can be upgraded in the field and a DHCPv6 client might only need to be an app, not an upgrade. From curtis@occnc.com Sun Sep 30 18:22: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 C6C0721F84EE for ; Sun, 30 Sep 2012 18:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=0.132, 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 zkQMHdoZshRE for ; Sun, 30 Sep 2012 18:22:00 -0700 (PDT) Received: from gateway1.orleans.occnc.com (gateway1.orleans.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id F0BF521F84EC for ; Sun, 30 Sep 2012 18:21:59 -0700 (PDT) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id q911Lsbp031067; Sun, 30 Sep 2012 21:21:54 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201210010121.q911Lsbp031067@gateway1.orleans.occnc.com> To: Wassim Haddad From: Curtis Villamizar In-reply-to: Your message of "Wed, 26 Sep 2012 10:26:27 PDT." <08880DCF-FEC8-4B52-8DB4-0300AC1EC811@ericsson.com> Date: Sun, 30 Sep 2012 21:21:53 -0400 Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Fwd: I-D Action: draft-haddad-homenet-multihomed-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 01:22:00 -0000 In message <08880DCF-FEC8-4B52-8DB4-0300AC1EC811@ericsson.com> Wassim Haddad writes: > Dear all, > > We have submitted a problem statement for multihoming in homenet. > Comments appreciated! > > Regards, > > Wassim H. Wassim, You are proposing a solution, not submitting a problem statement. A problem with your solution is that the most common multihoming is the mobile device having IP access through both WiFi (via DSL or cable or hotspot) and 4G mobile. In this case the "MSP middlebox" you propose would have to be inside the mobile device, which is already both one of the gateways and the end host. Another problem is the current non-existance of a Multihoming Service Provider (MSP)" somewhere out "in the cloud" to replace the source address of packets. No where in your document does the principle issue with multihoming get addressed. The source address used by the host must be chosen somehow by the host or replaced somewhere. The function of the "MSP middlebox" as described is only to redirect outgoing packets. If the source address reflect going through ISP2, and that link goes away, then the packets can now go out through ISP1 but the problem of using the wrong source address remains. If the source address is somehow provided by the MSP, then the traffic has to be tunnelled from MSP middlebox to MSP as might be implied by the last paragraph in section 4 where it says "In addition, if Gw1 and Gw2 provide addresses by the mean of DHCPv6 or RA, addresses at the MSPMB will be configured automatically as well". The word "address" barely appears in the draft except for the prior statement and one in the intro saying why Shim6 or MPTCP should not be used. The word "tunnel" doesn't appear at all. The word "source" (as in "source address") doesn't appear at all. So you don't seem to be proposing a viable solution or perhaps you had something to do with tunnelling in mind that you didn't describe at all clearly. Curtis > Begin forwarded message: > > > From: "internet-drafts@ietf.org" > > Subject: I-D Action: draft-haddad-homenet-multihomed-00.txt > > Date: September 25, 2012 10:55:38 AM PDT > > To: "i-d-announce@ietf.org" > > Reply-To: "internet-drafts@ietf.org" > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > > > > Title : Multihoming in Homenet > > Author(s) : Wassim Haddad > > Damien Saucez > > Joel Halpern > > Filename : draft-haddad-homenet-multihomed-00.txt > > Pages : 7 > > Date : 2012-09-25 > > > > Abstract: > > So far, multihoming in Homenet must be supported by the hosts as > > there is no mean to use simultaneously the different Internet Service > > Providers of the "Homenet" without risking flow disruption. In this > > memo, we describe the problem statement for multihoming in Homenet. > > We also propose a high level solution that answers this particular > > problem. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-haddad-homenet-multihomed > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-haddad-homenet-multihomed-00