From teco@inf-net.nl Sat Feb 1 02:31:14 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4894D1ACCF9 for ; Sat, 1 Feb 2014 02:31:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yBh7EpaH6yIR for ; Sat, 1 Feb 2014 02:31:12 -0800 (PST) Received: from mail-ee0-f45.google.com (mail-ee0-f45.google.com [74.125.83.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF801ACCF8 for ; Sat, 1 Feb 2014 02:31:09 -0800 (PST) Received: by mail-ee0-f45.google.com with SMTP id b15so2706742eek.32 for ; Sat, 01 Feb 2014 02:31:05 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=zRIMypKaz2+AtWYpzPbzzg33leBN8APKZK1bF/FH9/4=; b=LW/0i5qU3OE/EWK6+r1dUlltIKpcC4i1U337g+sKpA9rZJvvs2NzBEiBhAHsCkHK7y R+PTDLX7qYerp0CdLPpm5/awHcOPpgp4LBt1KeudkH0UUbZ52i6ivJbVxjodnNiU2qOm o1FtsKMwivBBnbqBzEzEK0Xp9k7zATkoSJA8hVKF0rH/86X7kfZWfVnmKwjU61+es9gv /PKX6espBZpwPl8sR2css+SsuBkigcBTh0k0evM5lgdsrgoyOqRl8cH3xNjrbXuWF1py bk9LmjURd3fbryxw/N5H5zpUCN2pDQYc1EMOWMXhMRmhL+8+nmYxbpXF1OiVeOsIlFyo EggQ== X-Gm-Message-State: ALoCoQlizaWpOvGHQWkyr1cE/Njs7eRSqEcIhlZn+ZF5smC7OHyiQBLeQ1CZbkJrDrXoLP9CaY2S X-Received: by 10.14.246.203 with SMTP id q51mr1031742eer.93.1391250664257; Sat, 01 Feb 2014 02:31:04 -0800 (PST) Received: from [10.175.173.95] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPSA id n7sm47834826eef.5.2014.02.01.02.31.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 01 Feb 2014 02:31:02 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Teco Boot In-Reply-To: Date: Sat, 1 Feb 2014 11:36:30 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <94EE2833-D5DC-4C42-8C11-EC0C1872D108@inf-net.nl> References: <92008593-9CB2-47F4-977E-E98BE8FCA1FB@inf-net.nl> <14528114-A0A6-444F-8BEB-3A033A52394D@employees.org> <268DD22D-2594-47D3-91AA-D120B13705CD@inf-net.nl> <5D4EAED8-33A8-4BDA-B004-4506DAD47B7C@employees.org> To: Ole Troan X-Mailer: Apple Mail (2.1827) Cc: "homenet@ietf.org Group" , Mikael Abrahamsson , Lorenzo Colitti Subject: Re: [homenet] Homenet protocol decisions X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2014 10:31:14 -0000 Op 31 jan. 2014, om 20:25 heeft Ole Troan het = volgende geschreven: >>=20 >> My opinion: put the prefix distribution protocol on top of NDP, so = all nodes are informed. >=20 > what are the arguments for involving hosts in the prefix assignment = protocol? > as opposed the existing router to hosts protocols (ND/DHCP). >=20 With multiple prefixes, hosts have to select. Hosts get smarter and know how to handle multiple paths (MPTCP and the = like). It isn't enough just to provide a prefix with lifetime. If the = router knows more, for example data rate and delay (fixed line, 3G/4G, = whatever), it shall pass it to the host. Teco From teco@inf-net.nl Sat Feb 1 02:39:56 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02C9A1ACCF8 for ; Sat, 1 Feb 2014 02:39:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eQZrwmWO53A9 for ; Sat, 1 Feb 2014 02:39:54 -0800 (PST) Received: from mail-ee0-f46.google.com (mail-ee0-f46.google.com [74.125.83.46]) by ietfa.amsl.com (Postfix) with ESMTP id 1A9581ACCE6 for ; Sat, 1 Feb 2014 02:39:53 -0800 (PST) Received: by mail-ee0-f46.google.com with SMTP id c13so2704078eek.19 for ; Sat, 01 Feb 2014 02:39:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=7LOa921gGm9H+nDBGoNOloxLcqbfVFKtJ3+f2ruE8Ik=; b=B6iM55Caj/ZpTcni7pjULXS3XdB/iVscroGEdsHA0IC7usPxrJxfHut+zkvTF4V6lM HCTblGtif5eyWj+uVt/l5NPWGQsQJTXc3q0SRpcd0b34jm0JY0VzSYfzh8BPdWoNWXOe zZKBtzm2NYoYzzKw78mWDREWrQNFDLOo4jrRqL0M/HjawjClq6zox9Di64shjeFycrTy m3xOCGAB5BOCmX8E1Bb2gabxb1sHikhZbGH4WxytL0Ev939vZxRwbD7WG/w6YVzi8grC FbGx6+7n0pFD1ix0KG2+aKao3YE72EbuhQ57GQOrZW+rZIzQhuYITyRKtMtTraDf/fE4 L30Q== X-Gm-Message-State: ALoCoQkoZnj1FgUXYIHdNyqMzbGCV/KV/MO+q5i6Pea4MRq/DE9d4T6PoHPvkWq3AhXy2zhYOewo X-Received: by 10.14.69.200 with SMTP id n48mr24667015eed.54.1391251189798; Sat, 01 Feb 2014 02:39:49 -0800 (PST) Received: from [10.175.173.95] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPSA id m9sm34680946eeh.3.2014.02.01.02.39.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 01 Feb 2014 02:39:49 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Teco Boot In-Reply-To: Date: Sat, 1 Feb 2014 11:45:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <86D0DCEC-C01D-49CA-AA54-93666180B37C@inf-net.nl> References: <5B7762A1-F133-4274-A241-7CF02BD8F8A9@inf-net.nl> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1827) Cc: Ole Troan , "homenet@ietf.org Group" , Mikael Abrahamsson Subject: Re: [homenet] Homenet protocol decisions X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2014 10:39:56 -0000 Op 31 jan. 2014, om 19:56 heeft Lorenzo Colitti het = volgende geschreven: >> On Fri, Jan 31, 2014 at 10:54 AM, Teco Boot wrote: >> > And what happens when the routing protocol finds out that, even = though the delegation protocol thinks everything is OK and addresses = were delegated just fine, the network is now partitioned? How do you = reassign addresses in that case? >>=20 >> I don't see a problem. If the two partitions have border router(s), = addresses for the prefixes for the connected border router keeps = functioning. Prefixes for the disconnected border router(s) should be = deprecated. Is is an internal function on the router, based on topology = information and configured prefixes, provided by routing protocol and = prefix distribution protocol. >>=20 >> > How do you tell the prefix assignment protocol that it needs to = resolve addressing conflicts when you merge two networks that have the = same prefixes? >>=20 >> First we have to verify if this can happen. My favorite is using = DHCP-PD with server on CPE (edge) box (and elected box for ULA). This = box should circumvent your scenario. >>=20 > Er, *what*? You are aware that if you have a partition, one of the two = partitions will not be able to reach the DHCP server? Does it matter? Prefixes for unreachable DHCP servers should be = deprecated. Leases wil expire. A mobility tool is needed for connection = survival (MPTCP, whatever). Yes, here is a need for coupled routing and prefix management. The = routing table has state on connectivity to border routers. Prefix = management makes use of that. Where is the need for coupled protocols? Teco From otroan@employees.org Sat Feb 1 04:52:10 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D88891A059C for ; Sat, 1 Feb 2014 04:52:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id icptOG6FwOYX for ; Sat, 1 Feb 2014 04:52:09 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 8D4BF1A059A for ; Sat, 1 Feb 2014 04:52:09 -0800 (PST) X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFAK/t7FKQ/khN/2dsb2JhbABYgwy+b4EFFnSCJQEBBAF5BQsLRlcGiBAIzRoXjwkHgySBFASQP5oMgy47 X-IronPort-AV: E=Sophos;i="4.95,760,1384300800"; d="asc'?scan'208";a="4514636" Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-1.cisco.com with ESMTP; 01 Feb 2014 12:51:48 +0000 Received: from dhcp-10-61-100-59.cisco.com (dhcp-10-61-100-59.cisco.com [10.61.100.59]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s11CplQt009180 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 1 Feb 2014 12:51:47 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_81877BFF-3494-4670-BB9C-7536DDD3015F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ole Troan In-Reply-To: <94EE2833-D5DC-4C42-8C11-EC0C1872D108@inf-net.nl> Date: Sat, 1 Feb 2014 13:51:48 +0100 Message-Id: References: <92008593-9CB2-47F4-977E-E98BE8FCA1FB@inf-net.nl> <14528114-A0A6-444F-8BEB-3A033A52394D@employees.org> <268DD22D-2594-47D3-91AA-D120B13705CD@inf-net.nl> <5D4EAED8-33A8-4BDA-B004-4506DAD47B7C@employees.org> <94EE2833-D5DC-4C42-8C11-EC0C1872D108@inf-net.nl> To: Teco Boot X-Mailer: Apple Mail (2.1827) Cc: "homenet@ietf.org Group" , Mikael Abrahamsson , Lorenzo Colitti Subject: Re: [homenet] Homenet protocol decisions X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2014 12:52:11 -0000 --Apple-Mail=_81877BFF-3494-4670-BB9C-7536DDD3015F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Teco, >>> My opinion: put the prefix distribution protocol on top of NDP, so = all nodes are informed. >>=20 >> what are the arguments for involving hosts in the prefix assignment = protocol? >> as opposed the existing router to hosts protocols (ND/DHCP). >>=20 >=20 > With multiple prefixes, hosts have to select. yes. there isn't that much information the network has that it can tell = hosts though. as long as the network routes the packets the right way, I'm going to be = happy. in more convoluted networks with walled gardens and VPNs, the network = may pass the host more policy information, e.g. DNS server selection, = SAS/DAS policy and so on. > Hosts get smarter and know how to handle multiple paths (MPTCP and the = like). It isn't enough just to provide a prefix with lifetime. If the = router knows more, for example data rate and delay (fixed line, 3G/4G, = whatever), it shall pass it to the host. as the hosts gets smarter they'll be able to figure out the best end to = end path themselves. the network may pass meta data associated with prefixes to the hosts. = e.g. "usage of this prefix is horribly expensive". cheers, Ole --Apple-Mail=_81877BFF-3494-4670-BB9C-7536DDD3015F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJS7O3kAAoJEFuJXizso86gnYwH/AhXq/en8iF++HGtWdhmgnt9 tJKXnLfCcEl3dfVHEzGLAA4EjabkUZxDGsD7cH+J394IbeAiLGd6t3ex75UK3x/C rNnFpKZ0eX5HWCO3cHNs8GammLOF9gANx3ulXYgjsuqZVEn7mcGi1nD+RtpumWqR rD+HMTUlOF+6V4iHJ5og6vV/bwvT15Nf6rD852PrmX6DNcD/qg6x8rE/DMYqfhQb 8fLpVv6M+hO5u0AqkWNpQINeN1KhEmEUXGbardCmZc0GBumHUxGOjbVHRZ2BczWJ UA7ngZr8KU0wLRoUBtEnVDSBmwqId6CJO4BrIhrN+9EUD7ub3Rd+aPg29husJiY= =06c+ -----END PGP SIGNATURE----- --Apple-Mail=_81877BFF-3494-4670-BB9C-7536DDD3015F-- From jch@pps.univ-paris-diderot.fr Sat Feb 1 17:30:39 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB05F1A0012 for ; Sat, 1 Feb 2014 17:30:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uyI5rOqlg7A1 for ; Sat, 1 Feb 2014 17:30:38 -0800 (PST) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) by ietfa.amsl.com (Postfix) with ESMTP id 9956D1A0019 for ; Sat, 1 Feb 2014 17:30:37 -0800 (PST) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/46573) with ESMTP id s121TmwP000468 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 2 Feb 2014 02:29:48 +0100 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/46573) with ESMTP id s121TlxE022842; Sun, 2 Feb 2014 02:29:47 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 721346F24A; Sun, 2 Feb 2014 02:29:47 +0100 (CET) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id NI8DT-DmH-19; Sun, 2 Feb 2014 02:29:36 +0100 (CET) Received: from ijon.pps.jussieu.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 8C4656F241; Sun, 2 Feb 2014 02:29:36 +0100 (CET) Date: Sun, 02 Feb 2014 02:29:51 +0100 Message-ID: <87iosy2tf4.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Ole Troan In-Reply-To: References: User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Sun, 02 Feb 2014 02:29:48 +0100 (CET) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Sun, 02 Feb 2014 02:29:47 +0100 (CET) X-Miltered: at korolev with ID 52ED9F8C.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 52ED9F8B.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 52ED9F8C.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 52ED9F8B.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 52ED9F8C.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 52ED9F8B.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Homenet protocol decisions X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Feb 2014 01:30:40 -0000 Hi Ole, > We need to decide, if we want prefix assignment and distribution of other > configuration information integrated in a routing protocol. There's two orthogonal decisions. One is whether to make the configuration protocol a subprotocol of the routing protocol. (I have mentioned earlier that I very strongly favour a separate configuration protocol, I won't repeat my arguments here.) The other is to what extent "other configuration information" should be carried by the Homenet Configuration Protocol. The principled solution would be to mandate site-local multicast, and have application-layer protocols design their own discovery mechanisms (the end-to-end argument and all that). The pragmatic solution would be to include the kitchen sink in the configuration protocol. (My gut feeling is for an extensible configuration protocol that can carry arbitrary extra information, but that's simply because I don't have any experience with site-local multicast. I hope somebody can convince me that we can take site-local multicast for granted.) -- Juliusz From jch@pps.univ-paris-diderot.fr Sat Feb 1 18:12:08 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEE621A0023 for ; Sat, 1 Feb 2014 18:12:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TnLj_EBxMG6e for ; Sat, 1 Feb 2014 18:12:07 -0800 (PST) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) by ietfa.amsl.com (Postfix) with ESMTP id 5D0781A0021 for ; Sat, 1 Feb 2014 18:12:06 -0800 (PST) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/46573) with ESMTP id s122C0hN005307 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 2 Feb 2014 03:12:00 +0100 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/46573) with ESMTP id s122C0jG026499; Sun, 2 Feb 2014 03:12:00 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 80F606F24C; Sun, 2 Feb 2014 03:12:00 +0100 (CET) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id qxZjdPKRQuEm; Sun, 2 Feb 2014 03:11:29 +0100 (CET) Received: from ijon.pps.jussieu.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 6716C6F241; Sun, 2 Feb 2014 03:11:29 +0100 (CET) Date: Sun, 02 Feb 2014 03:11:44 +0100 Message-ID: <87bnyq2rhb.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Lorenzo Colitti In-Reply-To: References: User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Sun, 02 Feb 2014 03:12:00 +0100 (CET) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Sun, 02 Feb 2014 03:12:00 +0100 (CET) X-Miltered: at korolev with ID 52EDA970.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 52EDA970.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 52EDA970.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 52EDA970.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 52EDA970.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 52EDA970.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Homenet protocol decisions X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Feb 2014 02:12:09 -0000 > And what happens when the routing protocol finds out that, even though the > delegation protocol thinks everything is OK and addresses were delegated just > fine, the network is now partitioned? How do you reassign addresses in that > case? I fail to see how this particular functionality requires merging the two protocols. If a link is partitioned, you need to time-out the address assignments made by the now unreachable router. Whether they are timed out by the routing protocol or by a separate configuration protocol is pretty much an implementation detail, isn't it? > How do you tell the prefix assignment protocol that it needs to resolve > addressing conflicts when you merge two networks that have the same prefixes? > You have to tightly couple prefix assignment and routing again. If I were to implement this, I'd probably listen for changes to the kernel's routing table and defend my address whenever in doubt. (Being the paranoid type, I'd also flood periodic defense packets every few minutes, just in case.) > In which case it's just better to have the same protocol There are other disadvantages to having a single protocol. It's a tradeoff, as usual. -- Juliusz From dave.taht@gmail.com Sat Feb 1 19:15:51 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7AD1A003C for ; Sat, 1 Feb 2014 19:15:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wbg_3RnId6mH for ; Sat, 1 Feb 2014 19:15:45 -0800 (PST) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id B2F461A0027 for ; Sat, 1 Feb 2014 19:15:45 -0800 (PST) Received: by mail-qc0-f182.google.com with SMTP id c9so9239795qcz.41 for ; Sat, 01 Feb 2014 19:15:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=SGsFu7IIzbEASNuOQQAqY0RjUoRp8JMYGBRSm+0DcxU=; b=AheechO3YW12kwTFlkfoCgzlUJxOZOdpr0S0KEMCyIALN7uIaRAdQRO99t6Ks+y5bm ccpLoAufhJWM/mzFr3ikWmfd/yasjYpnVOieQZ43y7x3rKHH+lwjbeW0lY8YHcLfEyJf d95Tjh7oMwNYxp3xlUwMFaJ5ktGCP6qjfM1t+xmQNG99HrFsmWBKatULFamRCkD+3shN 0fHdnq03EXirADAAgUchIXzu0UVdOx+tMBqZ5IAx8zRirKTuj2EqE5r6u6sbYZFCGoss 1WBxnG0Ipgk2CtYgjy3G2BVF81H+q6l8T8ZHS7B813HujppWDeiTjcRryUf/d+NDL8ox Mlzg== MIME-Version: 1.0 X-Received: by 10.224.28.197 with SMTP id n5mr42181613qac.43.1391310941424; Sat, 01 Feb 2014 19:15:41 -0800 (PST) Received: by 10.224.42.70 with HTTP; Sat, 1 Feb 2014 19:15:41 -0800 (PST) Date: Sat, 1 Feb 2014 19:15:41 -0800 Message-ID: From: Dave Taht To: HOMENET Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [homenet] the homenet vision X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Feb 2014 03:15:51 -0000 Mark Townsley just gave a very nice presentation at uknof about what we are trying to accomplish here: https://plus.google.com/u/0/+MarcLuethi/posts/7GWKu1sFMw8 I have a few comments but I'll refrain til the superbowl. --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html From brian.e.carpenter@gmail.com Sat Feb 1 19:43:33 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 381D51A0040 for ; Sat, 1 Feb 2014 19:43:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ek-wsGqfRNto for ; Sat, 1 Feb 2014 19:43:31 -0800 (PST) Received: from mail-pb0-x232.google.com (mail-pb0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 757FB1A0041 for ; Sat, 1 Feb 2014 19:43:31 -0800 (PST) Received: by mail-pb0-f50.google.com with SMTP id rq2so5880058pbb.9 for ; Sat, 01 Feb 2014 19:43:27 -0800 (PST) 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=/EWhNBcncGrwQXjNNFrV5b8dRflTeQNxC3YMe7pjpDA=; b=vOmpldjRyiSokM9Ntn2frAajHK3Mid2z369jnNfLqPSzP1AFh9GhP4uTiqmpb/Whu9 pquRtNSORELWFiDIA0ahV6Z/qHh/fm/A0X/KBnBmPhHi9Ta0dQxOXdk8F+TMQgbbShUL Ar9CX/w4rcR68qMnZ2FdA2hOzvDpNQameVaijMyYdUP3HsJlSXYM5o+nD9VeBFu7ZASR b6DgYHH+kszmhAja27aZKpUdSUou+8qKbk946Mwv4oOSqn8XRrFLGR26bci4SJMV9hLK fSsS78t3ivMmtDk0onq89APttxa3I5OI77ZqPmXX350RXuTTgkFMhF1VBibszRtaVun3 p7dQ== X-Received: by 10.66.50.105 with SMTP id b9mr29770252pao.9.1391312607432; Sat, 01 Feb 2014 19:43:27 -0800 (PST) Received: from [192.168.178.23] (187.199.69.111.dynamic.snap.net.nz. [111.69.199.187]) by mx.google.com with ESMTPSA id ei4sm42420752pbb.42.2014.02.01.19.43.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 01 Feb 2014 19:43:26 -0800 (PST) Message-ID: <52EDBEDA.1020208@gmail.com> Date: Sun, 02 Feb 2014 16:43:22 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Juliusz Chroboczek References: <87iosy2tf4.wl%jch@pps.univ-paris-diderot.fr> In-Reply-To: <87iosy2tf4.wl%jch@pps.univ-paris-diderot.fr> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Ole Troan , "homenet@ietf.org Group" Subject: Re: [homenet] Homenet protocol decisions X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Feb 2014 03:43:33 -0000 Juliusz, You (and others) who speak of a "Homenet Configuration Protocol" seem to be making an assumption which is far from clear to me. That assumption is that config parameters in a homenet will come in some sense top-down from a higher level source of authority. I think that's a false assumption. It's derived from the old-style management of campus and enterprise networks, where there *is* a source of authority that also understands how to configure a network. That simply doesn't exist in a homenet, especially when we move away from the single-CPE flat network to the much more complex networks we expect in the future. I think we need a completely different approach. Just by chance, I happen to have one in mind. It's discussed for the case of carrier networks in http://tools.ietf.org/html/draft-jiang-config-negotiation-ps-02 I believe that exactly the same approach is needed for homenets. Regards Brian On 02/02/2014 14:29, Juliusz Chroboczek wrote: > Hi Ole, > >> We need to decide, if we want prefix assignment and distribution of other >> configuration information integrated in a routing protocol. > > There's two orthogonal decisions. > > One is whether to make the configuration protocol a subprotocol of the > routing protocol. (I have mentioned earlier that I very strongly favour > a separate configuration protocol, I won't repeat my arguments here.) > > The other is to what extent "other configuration information" should > be carried by the Homenet Configuration Protocol. The principled > solution would be to mandate site-local multicast, and have > application-layer protocols design their own discovery mechanisms (the > end-to-end argument and all that). The pragmatic solution would be to > include the kitchen sink in the configuration protocol. > > (My gut feeling is for an extensible configuration protocol that can > carry arbitrary extra information, but that's simply because I don't > have any experience with site-local multicast. I hope somebody can > convince me that we can take site-local multicast for granted.) > > -- Juliusz > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > . > From lorenzo@google.com Sat Feb 1 21:42:21 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31F6F1A004D for ; Sat, 1 Feb 2014 21:42:21 -0800 (PST) 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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lamibKd7cQPR for ; Sat, 1 Feb 2014 21:42:19 -0800 (PST) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id 921361A0031 for ; Sat, 1 Feb 2014 21:42:19 -0800 (PST) Received: by mail-ig0-f180.google.com with SMTP id m12so2245794iga.1 for ; Sat, 01 Feb 2014 21:42:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=gmbiH3Qv2DqVnC4rMJlke4iLQeLwU14bm6qEfv4/b8E=; b=htRbKW5wRcU+GMzNkxjRXbf9z2DOMU2KUYAxYu5WPFJAkPH3R2czQflRDWuMimjCr0 6GgOZ+Ob/BGGXYrLNn5pBYKZ+h2G0wOTj9QtZ6qGZcnlB6yjEl91WAu6cI10dHxYc5DK ysX6zeoJhy8qxZ3Sj922ixFApTnIWonrlPdM04cAjxNJJPHmk40jMRKKetajdvebqlyc 3kMKu/MGdfMx9woPauYQEMJhyvm398WKL8+7G5fLbP2dk69GVigd69AUOyFXbbrCxrg3 24p2lsyu8217RGxlXE9c4Fi+lyzmIWLPZ5qngx+FK1G8CtQ4g52vFBDt2knKNwrM5DeM duZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=gmbiH3Qv2DqVnC4rMJlke4iLQeLwU14bm6qEfv4/b8E=; b=Y+3Chl63lm6bHRaiPCIL/n4Ls3G/sYEvIkRq1UH/SU2SBeouyPNVTM0Upbs9aMiO/f V6RnRQ91Cgf5cHxFaSMMUaggDSZixIMDiP/PomnPYk19+vBAS3MarzgtgqMqBQ9Kbp/Q an7tPYcTIpTcFqwfHtlo/dMgLyLVZjdkgemW99ix+ZMerTrK3MFsKPyubqJKOmiq/+wM p5ECi8o9zso0nVG8YKmP1D0KOqjseguc0t3u/oiifsoLsUgxtPsWnYun2e/P2GTG68th gmf0fj2EH/uxjxVznjzXcpXokh1m7kph7fLYRgeTSMeqht0dxhJoXXmD00PgcpoZw7FK jEWg== X-Gm-Message-State: ALoCoQmPK8fPZ1YwGr6kZnJjK0Sev5QN1E6HqZjz6vHRTjkGcQuSG5AkdHfRzuVzeZ3dWt0b3F+M0E82yumLXDzIby8dWGkkfedt0xlIBaLhZF3y+L9vldtskcElTs/ANyQwx6MpQYkKlmfKG/c7PfHNFtgcXdiCPuuL6NX3n3xvgHkGuRAntOLTCqfaaBDAOnxyTQ1Hcdlf X-Received: by 10.50.176.137 with SMTP id ci9mr6204714igc.31.1391319735124; Sat, 01 Feb 2014 21:42:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Sat, 1 Feb 2014 21:41:55 -0800 (PST) In-Reply-To: <86D0DCEC-C01D-49CA-AA54-93666180B37C@inf-net.nl> References: <5B7762A1-F133-4274-A241-7CF02BD8F8A9@inf-net.nl> <86D0DCEC-C01D-49CA-AA54-93666180B37C@inf-net.nl> From: Lorenzo Colitti Date: Sat, 1 Feb 2014 21:41:55 -0800 Message-ID: To: Teco Boot Content-Type: multipart/alternative; boundary=089e0111e0da94fb0a04f165dee9 Cc: Ole Troan , "homenet@ietf.org Group" , Mikael Abrahamsson Subject: Re: [homenet] Homenet protocol decisions X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Feb 2014 05:42:21 -0000 --089e0111e0da94fb0a04f165dee9 Content-Type: text/plain; charset=UTF-8 On Sat, Feb 1, 2014 at 2:45 AM, Teco Boot wrote: > >> First we have to verify if this can happen. My favorite is using > DHCP-PD with server on CPE (edge) box (and elected box for ULA). This box > should circumvent your scenario. > >> > > Er, *what*? You are aware that if you have a partition, one of the two > partitions will not be able to reach the DHCP server? > > Does it matter? Prefixes for unreachable DHCP servers should be > deprecated. Leases wil expire. A mobility tool is needed for connection > survival (MPTCP, whatever). > You can't reliably deprecate information in DHCP. Even if the client supports the reconfigure option, deprecating something in DHCP requires that the server that has the original nonce still be up and around. This is why DHCP is not a good protocol to use in a distributed, unreliable network like a homenet. --089e0111e0da94fb0a04f165dee9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= at, Feb 1, 2014 at 2:45 AM, Teco Boot <teco@inf-net.nl> wrote:=
>> First we have to verify if this can happen.= My favorite is using DHCP-PD with server on CPE (edge) box (and elected bo= x for ULA). This box should circumvent your scenario.
>>
> Er, *what*? You are aware that if you have a partition, one of the two= partitions will not be able to reach the DHCP server?

Does it matter? Prefixes for unreachable DHCP servers should be= deprecated. Leases wil expire. A mobility tool is needed for connection su= rvival (MPTCP, whatever).

You can't= reliably deprecate information in DHCP. Even if the client supports the re= configure option, deprecating something in DHCP requires that the server th= at has the original nonce still be up and around.

This is why DHCP is not a good protocol to use in a dis= tributed, unreliable network like a homenet.
--089e0111e0da94fb0a04f165dee9-- From lorenzo@google.com Sat Feb 1 21:46:19 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2C321A004D for ; Sat, 1 Feb 2014 21:46:19 -0800 (PST) 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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D6JkRqOPbjph for ; Sat, 1 Feb 2014 21:46:18 -0800 (PST) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id E7A351A0031 for ; Sat, 1 Feb 2014 21:46:17 -0800 (PST) Received: by mail-ig0-f170.google.com with SMTP id m12so3789821iga.1 for ; Sat, 01 Feb 2014 21:46:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=0uAsKcAtL32Th2TuPm5yydlaqy0ENHSKwW1UZK7OJU0=; b=PB6xiyt6yB1b3o4LbxB9z/0x5fEEOjYBnOP4y5mTqKrd7xa1sGMaVNLLbXnEoeLO6F 6jagB5rjtXum07l5Wp8iOzdncDRVXnUPncol1OHyfplVn9Rise89yShTYHjdkKfv0hjt E7HFsaodCjZUFdstrKNVfPPaoS+vb22vdYIYHos8iKDf5jvQoiFjtPpsAKX8XHBU2zdi bh2JMTkgMC+9KUdbqPm14K3IgQkCIQ3jCW8nZIIbScdTlJVmlWeQM+sMzHTqQB0q98oC pbh1XDo8EhDjpRIvtBc8EcZyEJfHLgY0kyPIKIZeOMse3BS6TqxFx0upyMfHzWfFMdsT QB6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=0uAsKcAtL32Th2TuPm5yydlaqy0ENHSKwW1UZK7OJU0=; b=hui7PpeOhzxRHVyCu5ChV2llNWjuVjH5JEiQpyJOZpKSYtxeJseUxMZObfbHLjtgFo TBjjFZv5Cq/vJoKCU3yuiI/mc+oOYR4D6GVoMWvzni4H1XqmhVBiFZAtSIMWjrfjSpU2 Nb0rvb8VpvtA6jZEOks2hRL9llVQH8aPSBkvrbI951Gq2BVRIcj1kNAyY6nE2zPkd0x0 JZhVXm0yhPzo7TCKoEHKb4Im88hXrQAnYUBgs2Fa19BeX5xKcuUui55GLbAxXJPtckZv W/jS/r7p2RhI9jqUxwLe67pwPNfjwm86DET76jipYvfo+kXAZF3CVO+MxizmGQQT03cr hjow== X-Gm-Message-State: ALoCoQnEVMe57729TrQXz0UXBXEzWGao0n/OUn4BMBW3IrAB5YeBlG1MHfeSiCwCxnJoMqomts0a9E2DrQymnpHuRw/V9HJ+dpFkWzjIrKmatqm7E8SIJIhujoI/z4LWUrjqhNMj89t59mi5u290d0HoyxSP4Cg2vQj9t9WtAtvio1wCoLd/eJpZ5FTjlJpf5uDrUbbIN5Pf X-Received: by 10.50.79.228 with SMTP id m4mr6034912igx.47.1391319973664; Sat, 01 Feb 2014 21:46:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Sat, 1 Feb 2014 21:45:53 -0800 (PST) In-Reply-To: <87bnyq2rhb.wl%jch@pps.univ-paris-diderot.fr> References: <87bnyq2rhb.wl%jch@pps.univ-paris-diderot.fr> From: Lorenzo Colitti Date: Sat, 1 Feb 2014 21:45:53 -0800 Message-ID: To: Juliusz Chroboczek Content-Type: multipart/alternative; boundary=089e013a1f16ccc5f004f165ecd9 Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Homenet protocol decisions X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Feb 2014 05:46:19 -0000 --089e013a1f16ccc5f004f165ecd9 Content-Type: text/plain; charset=UTF-8 On Sat, Feb 1, 2014 at 6:11 PM, Juliusz Chroboczek < jch@pps.univ-paris-diderot.fr> wrote: > > And what happens when the routing protocol finds out that, even though > the > > delegation protocol thinks everything is OK and addresses were delegated > just > > fine, the network is now partitioned? How do you reassign addresses in > that > > case? > > I fail to see how this particular functionality requires merging the > two protocols. If a link is partitioned, you need to time-out the > address assignments made by the now unreachable router. Whether they > are timed out by the routing protocol or by a separate configuration > protocol is pretty much an implementation detail, isn't it? > The routing protocol knows that the network is partitioned because that's what it does. How is the configuration distribution protocol going to know that? Either you couple it to the routing protocol, or you have it poll to see if things have changed (inefficient and/or slow to notice changes). Why would you do the latter? --089e013a1f16ccc5f004f165ecd9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= at, Feb 1, 2014 at 6:11 PM, Juliusz Chroboczek <jch@pps.univ-p= aris-diderot.fr> wrote:
> And what happens when= the routing protocol finds out that, even though the
> delegation protocol thinks everything is OK and addresses were delegat= ed just
> fine, the network is now partitioned? How do you reassign addresses in= that
> case?

I fail to see how this particular functionality requires merging the<= br> two protocols. =C2=A0If a link is partitioned, you need to time-out the
address assignments made by the now unreachable router. =C2=A0Whether they<= br> are timed out by the routing protocol or by a separate configuration
protocol is pretty much an implementation detail, isn't it?

The routing protocol knows that the network is par= titioned because that's what it does. How is the configuration distribu= tion protocol going to know that? Either you couple it to the routing proto= col, or you have it poll to see if things have changed (inefficient and/or = slow to notice changes). Why would you do the latter?
--089e013a1f16ccc5f004f165ecd9-- From swmike@swm.pp.se Sat Feb 1 23:07:16 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DFF51A005A for ; Sat, 1 Feb 2014 23:07:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J2H2u8B1io7c for ; Sat, 1 Feb 2014 23:07:14 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 5E8B71A0057 for ; Sat, 1 Feb 2014 23:07:13 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 9602FA1; Sun, 2 Feb 2014 08:07:08 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 8E8349C; Sun, 2 Feb 2014 08:07:08 +0100 (CET) Date: Sun, 2 Feb 2014 08:07:08 +0100 (CET) From: Mikael Abrahamsson To: Brian E Carpenter In-Reply-To: <52EDBEDA.1020208@gmail.com> Message-ID: References: <87iosy2tf4.wl%jch@pps.univ-paris-diderot.fr> <52EDBEDA.1020208@gmail.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Homenet protocol decisions X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Feb 2014 07:07:17 -0000 On Sun, 2 Feb 2014, Brian E Carpenter wrote: > Juliusz, > > You (and others) who speak of a "Homenet Configuration > Protocol" seem to be making an assumption which is far from > clear to me. That assumption is that config parameters in a homenet > will come in some sense top-down from a higher level source of > authority. No, I don't think that's what's assumed. All the discussions I've heard have been to have configuration sent around the home using a routing protocol, or another protocol that disseminates information around the home in a similar fashion. -- Mikael Abrahamsson email: swmike@swm.pp.se From ot@cisco.com Sun Feb 2 01:50:04 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9ABB1A00A2 for ; Sun, 2 Feb 2014 01:50:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V3VF-_211qbR for ; Sun, 2 Feb 2014 01:50:03 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 3D5001A00B1 for ; Sun, 2 Feb 2014 01:50:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1617; q=dns/txt; s=iport; t=1391334599; x=1392544199; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=sS7u6sAaBl4cSOo1B8F8MdS8IRCIKb8lc3pTLi6uTDE=; b=GnHNWEL0viCr6SzYESv3dkfA0141uOFtRxk7E/7k5wNzjxqNFsBjt+4x qOn8SK7f0tEil/OfoNJrqSj2aPUynmiYyg9TLwcP/qVBEzN7M7jwxfKYx R07GhMpkBnupbUyVWvcTRjjIxdMb145mfy2RAIhGpOhhOMuD45LiyMsLW M=; X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAGQU7lKQ/khN/2dsb2JhbABYgwy+cIEBFnSCJQEBAQMBeRALDjhXBogQCMw2F48JB4MkgRQBA5A/h2uSIYMuOw X-IronPort-AV: E=Sophos;i="4.95,760,1384300800"; d="asc'?scan'208";a="3872329" Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-2.cisco.com with ESMTP; 02 Feb 2014 09:49:43 +0000 Received: from dhcp-10-61-102-126.cisco.com (dhcp-10-61-102-126.cisco.com [10.61.102.126]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s129nfSs005547 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 2 Feb 2014 09:49:42 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_DE0DC3D1-C933-4D8D-A2D8-83EA46A1232F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ole Troan In-Reply-To: Date: Sun, 2 Feb 2014 10:49:17 +0100 Message-Id: <5129EF0F-14F9-4280-BCCB-4DF87E1862B7@cisco.com> References: <87iosy2tf4.wl%jch@pps.univ-paris-diderot.fr> <52EDBEDA.1020208@gmail.com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1827) Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Homenet protocol decisions X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Feb 2014 09:50:04 -0000 --Apple-Mail=_DE0DC3D1-C933-4D8D-A2D8-83EA46A1232F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >> You (and others) who speak of a "Homenet Configuration >> Protocol" seem to be making an assumption which is far from >> clear to me. That assumption is that config parameters in a homenet >> will come in some sense top-down from a higher level source of >> authority. >=20 > No, I don't think that's what's assumed. All the discussions I've = heard have been to have configuration sent around the home using a = routing protocol, or another protocol that disseminates information = around the home in a similar fashion. absolutely. any protocol here must support multiple sources of = information. cheers, Ole --Apple-Mail=_DE0DC3D1-C933-4D8D-A2D8-83EA46A1232F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJS7hSdAAoJEP0up8EdT99JqnYH/i0Z8x/5GgnwFgWhbF9DD6H7 BaZXLCuhwA0H9RtfrIvjnJkhUcafsD17Yvsw8hu8pLe1lxnMem9SQRolSQPDqx1a leTjdhTseRwH90zyhQ0/2BYwhGKgMdIFQotgv0jwGqa/QzscACBzfFhSVC+GS8vb hzlpAhTGG3SakURCqcVCZ+p7/2KOrVJTXovDzeXmG0ODvJc+FSqFBRFe6ph2m/8Z gtUhm6LDDkpWTyk/toJqYRg39V7Mk8iu0pJlo1qpur8P/eGlFerR3xD4mZrO7pM/ 3b0edN9M4mV9RCEZxG11c7siQ2blR0utCt3Wx/F3jUX5q6+0Mv769HG8cWA2+0Q= =DVmq -----END PGP SIGNATURE----- --Apple-Mail=_DE0DC3D1-C933-4D8D-A2D8-83EA46A1232F-- From jch@pps.univ-paris-diderot.fr Sun Feb 2 07:08:38 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D2111A00EE for ; Sun, 2 Feb 2014 07:08:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3eq1bgxdrcfd for ; Sun, 2 Feb 2014 07:08:37 -0800 (PST) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) by ietfa.amsl.com (Postfix) with ESMTP id B2C9E1A00D9 for ; Sun, 2 Feb 2014 07:08:36 -0800 (PST) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/46573) with ESMTP id s12F8UDE028350; Sun, 2 Feb 2014 16:08:30 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id D9FEA6F2B3; Sun, 2 Feb 2014 16:08:29 +0100 (CET) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id oz-zjNbGuoNx; Sun, 2 Feb 2014 16:08:28 +0100 (CET) Received: from ijon.pps.jussieu.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id E319D6F2B1; Sun, 2 Feb 2014 16:08:28 +0100 (CET) Date: Sun, 02 Feb 2014 16:08:28 +0100 Message-ID: <877g9do8lv.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Brian E Carpenter In-Reply-To: <52EDBEDA.1020208@gmail.com> References: <87iosy2tf4.wl%jch@pps.univ-paris-diderot.fr> <52EDBEDA.1020208@gmail.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Sun, 02 Feb 2014 16:08:30 +0100 (CET) X-Miltered: at korolev with ID 52EE5F6E.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 52EE5F6E.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 52EE5F6E.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Homenet protocol decisions X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Feb 2014 15:08:38 -0000 > You (and others) who speak of a "Homenet Configuration Protocol" > seem to be making an assumption [...] that config parameters in > a homenet will come in some sense top-down I don't think we are. (But you're right, this deserves stating explicitly.) I think that most of us have in mind a peer-to-peer protocol in which authoritative configuration information (notably prefix information) is flooded by the edge routers (CPEs), and dynamic information is negotiated dynamically both on a link-local basis (agreeing on a single prefix) and globally to the homenet (ensuring unicity). (I'm assuming just site-local unicast and multicast, hence the need for an application- layer flooding algorithm, I'm not sure if others are assuming site-local multicast.) As far as I am aware, this is the same model as the one in Acees' draft, except for the use of a flooding mechanism separate from OSPF's, and is in full agreement with the Arch document. -- Juliusz From acee.lindem@ericsson.com Sun Feb 2 08:47:16 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75B711A00DC for ; Sun, 2 Feb 2014 08:47:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xi5l5kQhpYyE for ; Sun, 2 Feb 2014 08:47:14 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 831061A00AC for ; Sun, 2 Feb 2014 08:47:14 -0800 (PST) X-AuditID: c618062d-b7f858e0000031c7-17-52ee76891a57 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 7D.61.12743.A867EE25; Sun, 2 Feb 2014 17:47:06 +0100 (CET) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0387.000; Sun, 2 Feb 2014 11:47:08 -0500 From: Acee Lindem To: Lorenzo Colitti Thread-Topic: [homenet] Homenet protocol decisions Thread-Index: AQHPHajdXgemXMpmhEat0Za7bl6aoJqeGN2AgAC+7ICAAJAhgIACKNIAgAA71YCAALgQAA== Date: Sun, 2 Feb 2014 16:47:07 +0000 Message-ID: References: <87bnyq2rhb.wl%jch@pps.univ-paris-diderot.fr> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: multipart/alternative; boundary="_000_FA7793D84E9A4AE2943BBC308D105D18ericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyuXRPgm5X2bsgg5WHhC3eLzrEYvH50z9W i/Wn3zE6MHss2FTqsWTJTyaPi7vfMQYwR3HZpKTmZJalFunbJXBl7J14hbXgj2zFtYZOxgbG hZJdjJwcEgImEndWzWCEsMUkLtxbz9bFyMUhJHCEUeLenA3MEM4yRomOPY1gVWwCOhLPH/1j BrFFBDQkHqw7zgRiMwukSpw4shgsLixgKNG19x4rRI2RxJV9C9gh7DCJfZuOsoDYLAIqEls+ /QObyStgL9F4eBcrxLJ/TBJnT25iA0lwCgRKfD9yG8xmBDrv+6k1UMvEJW49mc8EcbaAxJI9 55khbFGJl4//sULYihL7+qezQ9QnSzTc+s4OsUxQ4uTMJywTGEVnIRk1C0nZLCRlEHEdiQW7 P7FB2NoSyxa+Zoaxzxx4DNVrLdF+4Aw7spoFjByrGDlKi1PLctONDDYxAmPwmASb7g7GPS8t DzFKc7AoifN+eescJCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoGxwYW596/47mwz7fQDovpb XpzOEbvtkax48P+myGaJpdGro9982cvy9oX94cQLYb15YYr6v09L6fsJywUGF4r5/c3WXvvz 6x/Blg2TtdjTtkj1rjKvkhRdvGJzRLRL+o6tWcL6iz4w1F/fUywYa8nA514VuOpc68+fJ+T3 CMjtXzh7/wmWLV1KLMUZiYZazEXFiQAHaX+ujwIAAA== Cc: "homenet@ietf.org Group" , Juliusz Chroboczek Subject: Re: [homenet] Homenet protocol decisions X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Feb 2014 16:47:16 -0000 --_000_FA7793D84E9A4AE2943BBC308D105D18ericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree. Also, since we already have to bootstrap an auto-configuring routi= ng protocol, why not leverage this work to distribute other information? Acee On Feb 2, 2014, at 12:45 AM, Lorenzo Colitti wrote: On Sat, Feb 1, 2014 at 6:11 PM, Juliusz Chroboczek > wrote: > And what happens when the routing protocol finds out that, even though th= e > delegation protocol thinks everything is OK and addresses were delegated = just > fine, the network is now partitioned? How do you reassign addresses in th= at > case? I fail to see how this particular functionality requires merging the two protocols. If a link is partitioned, you need to time-out the address assignments made by the now unreachable router. Whether they are timed out by the routing protocol or by a separate configuration protocol is pretty much an implementation detail, isn't it? The routing protocol knows that the network is partitioned because that's w= hat it does. How is the configuration distribution protocol going to know t= hat? Either you couple it to the routing protocol, or you have it poll to s= ee if things have changed (inefficient and/or slow to notice changes). Why = would you do the latter? --_000_FA7793D84E9A4AE2943BBC308D105D18ericssoncom_ Content-Type: text/html; charset="us-ascii" Content-ID: <53967C6A0CD60949A6261D34F82ECA07@ericsson.com> Content-Transfer-Encoding: quoted-printable I agree. Also, since we already have to bootstrap an auto-configuring routi= ng protocol, why not leverage this work to distribute other information?&nb= sp;
Acee 

On Feb 2, 2014, at 12:45 AM, Lorenzo Colitti wrote:

On Sat, Feb 1, 2014 at 6:11 PM, Juliusz Chrobocz= ek <jch@= pps.univ-paris-diderot.fr> wrote:
> And what happens when the routing protocol finds out= that, even though the
> delegation protocol thinks everything is OK and addresses were delegat= ed just
> fine, the network is now partitioned? How do you reassign addresses in= that
> case?

I fail to see how this particular functionality requires merging the
two protocols.  If a link is partitioned, you need to time-out the
address assignments made by the now unreachable router.  Whether they<= br> are timed out by the routing protocol or by a separate configuration
protocol is pretty much an implementation detail, isn't it?

The routing protocol knows that the network is partitioned because tha= t's what it does. How is the configuration distribution protocol going to k= now that? Either you couple it to the routing protocol, or you have it poll= to see if things have changed (inefficient and/or slow to notice changes). Why would you do the latter?

--_000_FA7793D84E9A4AE2943BBC308D105D18ericssoncom_-- From jch@pps.univ-paris-diderot.fr Sun Feb 2 09:03:38 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C10E91A00ED for ; Sun, 2 Feb 2014 09:03:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g85aj-5_94iR for ; Sun, 2 Feb 2014 09:03:38 -0800 (PST) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) by ietfa.amsl.com (Postfix) with ESMTP id DBC731A00EA for ; Sun, 2 Feb 2014 09:03:37 -0800 (PST) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/46573) with ESMTP id s12H3VTX021152; Sun, 2 Feb 2014 18:03:31 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id B80D56F2B9; Sun, 2 Feb 2014 18:03:31 +0100 (CET) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id TGEXJdYbHF2d; Sun, 2 Feb 2014 18:03:30 +0100 (CET) Received: from ijon.pps.jussieu.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 94A636F17D; Sun, 2 Feb 2014 18:03:30 +0100 (CET) Date: Sun, 02 Feb 2014 18:03:28 +0100 Message-ID: <87y51tmopr.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Acee Lindem In-Reply-To: References: <87bnyq2rhb.wl%jch@pps.univ-paris-diderot.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Sun, 02 Feb 2014 18:03:31 +0100 (CET) X-Miltered: at korolev with ID 52EE7A63.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 52EE7A63.001 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 52EE7A63.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Homenet protocol decisions X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Feb 2014 17:03:38 -0000 > Also, since we already have to bootstrap an auto-configuring routing > protocol, why not leverage this work to distribute other information? As usual, it's a tradeoff, and the choice of tradeoff is dependent on one's background. Those of us who come from the Free Software chaos will prefer small, self-contained protocols that can be implemented by small, loosely coupled groups of developers, and that communicate through well- defined, stable APIs. Those who come from large, well-managed, centralised organisations will prefer large protocols, and won't want to bother with the tricky job of defining stable interfaces between loosely coupled software components. To put it differently -- with Dave's help, we should have no trouble pushing a self-contained configuration daemon into OpenWRT and from there to other Linux and BSD systems. We will find it somewhat more challenging to add the proposed sub-protocol to all of the Open Source implementations of OSPF and ensure that it's compiled-in by default. -- Juliusz From dave.taht@gmail.com Sun Feb 2 09:16:07 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1772B1A00EF for ; Sun, 2 Feb 2014 09:16:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_21=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W-mu_QO1wBcy for ; Sun, 2 Feb 2014 09:16:03 -0800 (PST) Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 3FE201A00ED for ; Sun, 2 Feb 2014 09:16:03 -0800 (PST) Received: by mail-qc0-f177.google.com with SMTP id i8so9739740qcq.22 for ; Sun, 02 Feb 2014 09:15:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=zRrxJjxnGg+kpkZuhgS/GaSTGEoeNE/wKoe5eAG4z+8=; b=R+rzs1dt4f5OHjrbBTwtKzJ3hejaekHTL/pno7cHXGevXNsBmOra1qtAgmV8g1z1vy ptvha5rY6oZy90QgwThbtH1hfo8+PyYH8k5Aby9Hth+G/tvP7PgKlyqphLbRK7fH/wam Dgl2ekx1er1uF0V7t8Ee4RL6GuulrGb/kcjU8enbELndEUCv3EJnvV+jdw3BPZVyE3p4 UYww4ez9wrwWdw8BplxFfkwPuZhIMozgGwHh98tf+qyUEEYvZIRScrrMALYFBXb0Qrjd Qg5DSERDxQ8f4oAPYR2CtDIwo8GQY7YKldjU0NQbvCJ3l7jcpKy2HYl6KT2onNh1hdZ8 ZhdA== MIME-Version: 1.0 X-Received: by 10.224.124.74 with SMTP id t10mr49508237qar.40.1391361358732; Sun, 02 Feb 2014 09:15:58 -0800 (PST) Received: by 10.224.42.70 with HTTP; Sun, 2 Feb 2014 09:15:58 -0800 (PST) In-Reply-To: References: <87bnyq2rhb.wl%jch@pps.univ-paris-diderot.fr> Date: Sun, 2 Feb 2014 09:15:58 -0800 Message-ID: From: Dave Taht To: Acee Lindem Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "homenet@ietf.org Group" , Juliusz Chroboczek , Lorenzo Colitti Subject: Re: [homenet] Homenet protocol decisions X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Feb 2014 17:16:07 -0000 On Sun, Feb 2, 2014 at 8:47 AM, Acee Lindem wrot= e: > I agree. Also, since we already have to bootstrap an auto-configuring > routing protocol, why not leverage this work to distribute other > information? Because routing protocol authors are generally hostile to adding what is effectively dhcp-like support to their protocols and daemons? > Acee > > On Feb 2, 2014, at 12:45 AM, Lorenzo Colitti wrote: > > On Sat, Feb 1, 2014 at 6:11 PM, Juliusz Chroboczek > wrote: >> >> > And what happens when the routing protocol finds out that, even though >> > the >> > delegation protocol thinks everything is OK and addresses were delegat= ed >> > just >> > fine, the network is now partitioned? How do you reassign addresses in >> > that >> > case? >> >> I fail to see how this particular functionality requires merging the >> two protocols. If a link is partitioned, you need to time-out the >> address assignments made by the now unreachable router. Whether they >> are timed out by the routing protocol or by a separate configuration >> protocol is pretty much an implementation detail, isn't it? > > > The routing protocol knows that the network is partitioned because that's > what it does. How is the configuration distribution protocol going to kno= w > that? Either you couple it to the routing protocol, or you have it poll t= o > see if things have changed (inefficient and/or slow to notice changes). W= hy > would you do the latter? Several comments: 1) The synchonicity problem exists for multiple layers of the stack. Take DNS for example, when addresses change, dns needs to change also. It's very hard with any form of centralized server for dns to make that fast or atomic. 2) All the interdependencies on config and routing and dns for a highly dynamic ipv6 world are forcing daemon writers to adopt a software bus structure to broadcast and respond to changes to various subsystems controlled by various daemons. In the linux world at least, system configuration information is propigated between daemons mostly along the dbus, and the openwrt folk have implemented a ubus that is lighter weight, that communicates between dhcpv6, dns, dhcpv4 and other daemons. So what's needed is a clear delination of responsibilties for acquiring and pushing out changes to the underlying network architecture, and it doesn't matter what protocol on the wire those run over. 3) So far in dealing with highly dynamic ipv6, and poor interfaces to DNS in particular in the real world, I despise it and go back to wanting a /48 distributed with my house, or at least, some way to buy one from my ISP. 4) In my case at least the prefix distribution problem aint' problem 'cause I just ship /128s everywhere I need 'em with AHCP. /me ducks Yes, distributing prefixes is needed. 5) To finally get to your own point, there is no need to poll at the protocol level, the daemons on the responsible routers need be aware of changes and push them. Ideally there is some level of authentication involved, particularly in changes pushed like "forcibly retract this ipv6 prefix and use this one instead because my provider just changed me for no f-ing good reason") We've demonstrated that a protocol like AHCP can do that, (and nobody is suggesting that AHCP as currently defined is sufficient, it merely serves as a convenient counter-example to the embed-everything-in-the-routing protocol thread, that anybody can install and run, as it's been available in linux for 6+ years....) 6) A well defined set of TLVs and actions for border discovery, nat detection in ipv4, and carrying dns, ntp, and other core services is needed no matter how they are distributed. 7) I generally despair of this entire debate, and wish more people were writing code, doing experiments, and working inside the real world. I hate that this discussion has ratholed on the method of distribution, rather on than on "what configuration information needs to be propagated inside the home on zigbee, wifi, lte, moca, homeplug, in order to have grandma be able to get her pr0n and meds from her high-tech wheelchair. " me, for example, am observing how src/dst routing works in the real world, and am trying to improve it, deal with bcp38 and vpn technolgies, etc. There is a lot of work to be done to defeat in detail all the existing problems, and I argue strongly for trying stuff, iterating, and trying more stuff, until a viable standard for these problem emerges... ... and that, is probably the basic beef I have in modifying an existing routing protocol. Solving configuration distribution and border discovery, and nat detection, and core service distribution - needs a design small, flexible, and rapidly iterate-able, and *separate*, for these problems. I certainly wish we could foresee all problems in advance; we obviously can't (two years on this thread running), something flexible and iterate-able is needed. > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html From mellon@fugue.com Sun Feb 2 10:01:19 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19BC51A00F5 for ; Sun, 2 Feb 2014 10:01:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.836 X-Spam-Level: X-Spam-Status: No, score=-1.836 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eVDA-lMjBcHK for ; Sun, 2 Feb 2014 10:01:18 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 397EE1A00F3 for ; Sun, 2 Feb 2014 10:01:18 -0800 (PST) Received: from [10.0.10.40] (c-174-62-147-182.hsd1.nh.comcast.net [174.62.147.182]) by toccata.fugue.com (Postfix) with ESMTPSA id 2CE8D238081B; Sun, 2 Feb 2014 13:01:12 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ted Lemon In-Reply-To: Date: Sun, 2 Feb 2014 13:01:11 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <825D7C90-EFD1-40D2-AE70-715C9BC75C10@fugue.com> References: <87bnyq2rhb.wl%jch@pps.univ-paris-diderot.fr> To: Dave Taht X-Mailer: Apple Mail (2.1827) Cc: "homenet@ietf.org Group" Subject: [homenet] Homenet Configuration Requirements X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Feb 2014 18:01:19 -0000 On Feb 2, 2014, at 12:15 PM, Dave Taht wrote: > I hate that this discussion has ratholed on the method of > distribution, rather on than on "what configuration information needs > to be propagated inside the home on zigbee, wifi, lte, moca, homeplug, > in order to have grandma be able to get her pr0n and meds from her > high-tech wheelchair. " This is a really good point. The architecture document is supposed to = have tried to address this, but I take it from your complaint that you = don't think it does. Could you provide some suggestions for what the = next steps to address this problem should be? From brian.e.carpenter@gmail.com Sun Feb 2 10:58:46 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB1B91A00FB for ; Sun, 2 Feb 2014 10:58:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_21=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hjWzRHoimWf0 for ; Sun, 2 Feb 2014 10:58:45 -0800 (PST) Received: from mail-pb0-x229.google.com (mail-pb0-x229.google.com [IPv6:2607:f8b0:400e:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4781A00F7 for ; Sun, 2 Feb 2014 10:58:45 -0800 (PST) Received: by mail-pb0-f41.google.com with SMTP id up15so6289059pbc.0 for ; Sun, 02 Feb 2014 10:58:40 -0800 (PST) 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=VqpA+rp9ZxTXm6VdkgBZdiAyOB0pFabGXburWXY0TEU=; b=0eW/tKPAOkrfAPRkf9oAIW3+tPL3LNbSsVoVxxUWtYzPlxhc3ARJRQguHgTHxKqiVE G7dceCAwiKkSI8p1dSZQtXOYwVOQ4HTMfzdAbiiSicp4GMadmw1fEq2o5H4VGvXtxM+r lLUIXu36ke0pGeuydLJ+TJ7hkMVH/mENrzZR3Pkcs0heG2D/LUImYhzKsbyqw9sPySv6 XfX9UNEr1HaXYQV/pLNfWs83W4moPfAUnDSMjKqBFgMSMqjQs6IabqxGGAI9hTiKmMIg VkOI1Li2jblq5H9sWyHkdrbmLZTP9HUpIoOUJ8uCSw1B32F/JlnMpQizhnAebkfdWyXM 6p3A== X-Received: by 10.68.130.169 with SMTP id of9mr33055150pbb.79.1391367520832; Sun, 02 Feb 2014 10:58:40 -0800 (PST) Received: from [192.168.178.23] (148.200.69.111.dynamic.snap.net.nz. [111.69.200.148]) by mx.google.com with ESMTPSA id xv2sm48596006pbb.39.2014.02.02.10.58.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 02 Feb 2014 10:58:39 -0800 (PST) Message-ID: <52EE9559.6060406@gmail.com> Date: Mon, 03 Feb 2014 07:58:33 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dave Taht References: <87bnyq2rhb.wl%jch@pps.univ-paris-diderot.fr> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Acee Lindem , Lorenzo Colitti , "homenet@ietf.org Group" , Juliusz Chroboczek Subject: Re: [homenet] Homenet protocol decisions X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Feb 2014 18:58:46 -0000 On 03/02/2014 06:15, Dave Taht wrote: > On Sun, Feb 2, 2014 at 8:47 AM, Acee Lindem wrote: >> I agree. Also, since we already have to bootstrap an auto-configuring >> routing protocol, why not leverage this work to distribute other >> information? > > Because routing protocol authors are generally hostile to adding > what is effectively dhcp-like support to their protocols and daemons? I think there's a reason for that "hostility", which is that in some sense everything other than routing is less fundamental, and we need to protect routing from the rest by isolating it. If routing fails, nothing else can work, after all. So there's a tendency to keep the routing protocols "pure". However, the great thing about routing protocols is that they really are very close to autonomic, and we need that instead of traditional top-down configuration. Despite the protests, I detect hints of top-downness in many of the messages on this thread. Apart from external routes and available global prefixes, what else *needs* to be top-down in a homenet? Brian > >> Acee >> >> On Feb 2, 2014, at 12:45 AM, Lorenzo Colitti wrote: >> >> On Sat, Feb 1, 2014 at 6:11 PM, Juliusz Chroboczek >> wrote: >>>> And what happens when the routing protocol finds out that, even though >>>> the >>>> delegation protocol thinks everything is OK and addresses were delegated >>>> just >>>> fine, the network is now partitioned? How do you reassign addresses in >>>> that >>>> case? >>> I fail to see how this particular functionality requires merging the >>> two protocols. If a link is partitioned, you need to time-out the >>> address assignments made by the now unreachable router. Whether they >>> are timed out by the routing protocol or by a separate configuration >>> protocol is pretty much an implementation detail, isn't it? >> >> The routing protocol knows that the network is partitioned because that's >> what it does. How is the configuration distribution protocol going to know >> that? Either you couple it to the routing protocol, or you have it poll to >> see if things have changed (inefficient and/or slow to notice changes). Why >> would you do the latter? > > Several comments: > > 1) The synchonicity problem exists for multiple layers of the stack. > Take DNS for example, when addresses change, dns needs to change also. > It's very hard with any form of centralized server for dns to make > that fast or atomic. > > 2) All the interdependencies on config and routing and dns for a > highly dynamic ipv6 world are forcing daemon writers to adopt a > software bus structure to broadcast and respond to changes to various > subsystems controlled by various daemons. > > In the linux world at least, system configuration information is > propigated between daemons mostly along the dbus, and the openwrt folk > have implemented a ubus that is lighter weight, that communicates > between dhcpv6, dns, dhcpv4 and other daemons. > > So what's needed is a clear delination of responsibilties for > acquiring and pushing out changes to the underlying network > architecture, and it doesn't matter what protocol on the wire those > run over. > > 3) So far in dealing with highly dynamic ipv6, and poor interfaces to > DNS in particular in the real world, I despise it and go back to > wanting a /48 distributed with my house, or at least, some way to buy > one from my ISP. > > 4) In my case at least the prefix distribution problem aint' problem > 'cause I just ship /128s everywhere I need 'em with AHCP. > > /me ducks > > Yes, distributing prefixes is needed. > > 5) To finally get to your own point, there is no need to poll at the > protocol level, the daemons on the responsible routers need be aware > of changes and push them. Ideally there is some level of > authentication involved, > particularly in changes pushed like "forcibly retract this ipv6 prefix > and use this one instead because my provider just changed me for no > f-ing good reason") > > We've demonstrated that a protocol like AHCP can do that, (and nobody > is suggesting that AHCP as currently defined is sufficient, it merely > serves as a convenient counter-example to the > embed-everything-in-the-routing protocol thread, that anybody can > install and run, as it's been available in linux for 6+ years....) > > 6) A well defined set of TLVs and actions for border discovery, nat > detection in ipv4, and carrying dns, ntp, and other core services is > needed no matter how they are distributed. > > 7) I generally despair of this entire debate, and wish more people > were writing code, doing experiments, and working inside the real > world. I hate that this discussion has ratholed on the method of > distribution, rather on than on "what configuration information needs > to be propagated inside the home on zigbee, wifi, lte, moca, homeplug, > in order to have grandma be able to get her pr0n and meds from her > high-tech wheelchair. " > > me, for example, am observing how src/dst routing works in the real > world, and am trying to improve it, deal with bcp38 and vpn > technolgies, etc. There is a lot of work to be done to defeat in > detail all the existing problems, and I argue strongly for trying > stuff, iterating, and trying more stuff, until a viable > standard for these problem emerges... > > ... and that, is probably the basic beef I have in modifying an > existing routing protocol. Solving configuration distribution and > border discovery, and nat detection, and core service distribution - > needs a design small, flexible, and rapidly iterate-able, and > *separate*, for these problems. > > I certainly wish we could foresee all problems in advance; we > obviously can't (two years on this thread running), something flexible > and iterate-able is needed. > >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet >> > > > From jch@pps.univ-paris-diderot.fr Sun Feb 2 11:18:08 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 217A81A00FE for ; Sun, 2 Feb 2014 11:18:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eQQguxvM8ydh for ; Sun, 2 Feb 2014 11:18:06 -0800 (PST) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) by ietfa.amsl.com (Postfix) with ESMTP id 728391A00FF for ; Sun, 2 Feb 2014 11:18:06 -0800 (PST) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/46573) with ESMTP id s12JI1WS015655; Sun, 2 Feb 2014 20:18:01 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id EF6566F2D3; Sun, 2 Feb 2014 20:18:00 +0100 (CET) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id Vpu5-axKBXtG; Sun, 2 Feb 2014 20:18:00 +0100 (CET) Received: from ijon.pps.jussieu.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 17E576F2D2; Sun, 2 Feb 2014 20:18:00 +0100 (CET) Date: Sun, 02 Feb 2014 20:17:59 +0100 Message-ID: <877g9dmihk.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Brian E Carpenter In-Reply-To: <52EE9559.6060406@gmail.com> References: <87bnyq2rhb.wl%jch@pps.univ-paris-diderot.fr> <52EE9559.6060406@gmail.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Sun, 02 Feb 2014 20:18:01 +0100 (CET) X-Miltered: at korolev with ID 52EE99E9.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 52EE99E9.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 52EE99E9.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Homenet protocol decisions X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Feb 2014 19:18:08 -0000 > Despite the protests, I detect hints of top-downness in many of the > messages on this thread. Yes, it's an easy mistake to make. You're right, we should be very vigilant about that. -- Juliusz From dave.taht@gmail.com Sun Feb 2 11:20:48 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5440E1A0100 for ; Sun, 2 Feb 2014 11:20:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_21=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5swAFVlCyerP for ; Sun, 2 Feb 2014 11:20:44 -0800 (PST) Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 777C81A00FF for ; Sun, 2 Feb 2014 11:20:44 -0800 (PST) Received: by mail-qc0-f181.google.com with SMTP id e9so9811306qcy.40 for ; Sun, 02 Feb 2014 11:20:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=fDOOs25VLMxUQz8YJ0Jji2z5EGlooYPSrFH+OiAc+II=; b=d9jyCx2vaRN2WRDaHdUtBu7IvOVqEZmrTxTpT7osborHrfXPvbhyPJbfvhobtC4WxW iHOYl89NS1/tLDGqoFX4HMX9ujd1iH6NEofagguU21i1+nQO9cJSSH18qkduXz62RFyk 4DSuTQYRCY9+Hp78/+F+ZwyXOAECZLW91MZ2QGs4ZAMRyGCAQtp0yZTUFzyCzPp/nzqW mJj8Qbsn4OGkp5ujUBLbx5rWniTE6rSVAZM49QiSymviXedMaVD7Zjxkwh8fYzq7OTg2 uoejpDM2n2BItLPSK88EnOipsRe/XQ7r4/j/Ge9ARBnwSIXdEBzx4rNUbKzc4ZO4I3Eo 536A== MIME-Version: 1.0 X-Received: by 10.140.89.241 with SMTP id v104mr47992642qgd.27.1391368839918; Sun, 02 Feb 2014 11:20:39 -0800 (PST) Received: by 10.224.42.70 with HTTP; Sun, 2 Feb 2014 11:20:39 -0800 (PST) In-Reply-To: <52EE9559.6060406@gmail.com> References: <87bnyq2rhb.wl%jch@pps.univ-paris-diderot.fr> <52EE9559.6060406@gmail.com> Date: Sun, 2 Feb 2014 11:20:39 -0800 Message-ID: From: Dave Taht To: Brian E Carpenter Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Acee Lindem , Lorenzo Colitti , "homenet@ietf.org Group" , Juliusz Chroboczek Subject: Re: [homenet] Homenet protocol decisions X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Feb 2014 19:20:48 -0000 On Sun, Feb 2, 2014 at 10:58 AM, Brian E Carpenter wrote: > On 03/02/2014 06:15, Dave Taht wrote: >> On Sun, Feb 2, 2014 at 8:47 AM, Acee Lindem w= rote: >>> I agree. Also, since we already have to bootstrap an auto-configuring >>> routing protocol, why not leverage this work to distribute other >>> information? >> >> Because routing protocol authors are generally hostile to adding >> what is effectively dhcp-like support to their protocols and daemons? > > I think there's a reason for that "hostility", which is that in some > sense everything other than routing is less fundamental, and we need > to protect routing from the rest by isolating it. If routing fails, > nothing else can work, after all. So there's a tendency to keep > the routing protocols "pure". I will definately argue that a more extensible protocol than a routing protocol or dhcp as currently defined is needed for configuration. given the ubiquity of http servers, additional configuration could be carried by propagating a configuration server url around (and or leveraging sddp/upnp/pcp/dns-sd). > However, the great thing about routing protocols is that they really > are very close to autonomic, and we need that instead of traditional > top-down configuration. Despite the protests, I detect hints of > top-downness in many of the messages on this thread. Apart from > external routes and available global prefixes, what else *needs* > to be top-down in a homenet? 1) What time is it? I would personally like it if ntp over ipv6 was encrypted and multicast within your own borders. I'd settle for all boxes within a homenet agreeing on the same set of what local time servers are definitive. 2) Where are my dns server(s)? What do they serve addresses for? The dns scoping problem has not been addressed here, and it gets horribly complex rapidly in the presence of multiple isps, vpns, and other services like the nest stuff. Your vpn is probably going into split dns in particular... 3) As a couple straw men... my opposition to iw10 universally is probably pretty well known. The relevant rfc and research in favor of it was skewed in favor of stuff coming from high speed/high bandwidth servers... http://tools.ietf.org/html/draft-ietf-tcpm-initcwnd-00 ...instead of the behavior of apps sending stuff from your local (much slower) network to the internet. http://tools.ietf.org/id/draft-gettys-iw10-considered-harmful-00.txt The observable spike from iw10 is quite large on egress from slower networks, and especially damaging on single queue aqm systems like codel and pie. now it turns out iw10 (initcwnd), mtu, and can be set on a per route basis (at least in linux), and I would not mind at all if my route to the each source specific gw to the internet from my slower net advertised a saner iw, and correct pmtu. That is pretty top-down, and it would be probably best to carry that info in the routing protocol. (/me ducks) 4) There is a long list of things supplied currently by dhcp, many of which are obsolete (impress server anyone?), that would be worth going through in detail. I imagine that there are multiple rfc's following this one: http://tools.ietf.org/search/rfc2132 there are many lessons to be learned from dhcp. > > Brian > >> >>> Acee >>> >>> On Feb 2, 2014, at 12:45 AM, Lorenzo Colitti wrote: >>> >>> On Sat, Feb 1, 2014 at 6:11 PM, Juliusz Chroboczek >>> wrote: >>>>> And what happens when the routing protocol finds out that, even thoug= h >>>>> the >>>>> delegation protocol thinks everything is OK and addresses were delega= ted >>>>> just >>>>> fine, the network is now partitioned? How do you reassign addresses i= n >>>>> that >>>>> case? >>>> I fail to see how this particular functionality requires merging the >>>> two protocols. If a link is partitioned, you need to time-out the >>>> address assignments made by the now unreachable router. Whether they >>>> are timed out by the routing protocol or by a separate configuration >>>> protocol is pretty much an implementation detail, isn't it? >>> >>> The routing protocol knows that the network is partitioned because that= 's >>> what it does. How is the configuration distribution protocol going to k= now >>> that? Either you couple it to the routing protocol, or you have it poll= to >>> see if things have changed (inefficient and/or slow to notice changes).= Why >>> would you do the latter? >> >> Several comments: >> >> 1) The synchonicity problem exists for multiple layers of the stack. >> Take DNS for example, when addresses change, dns needs to change also. >> It's very hard with any form of centralized server for dns to make >> that fast or atomic. >> >> 2) All the interdependencies on config and routing and dns for a >> highly dynamic ipv6 world are forcing daemon writers to adopt a >> software bus structure to broadcast and respond to changes to various >> subsystems controlled by various daemons. >> >> In the linux world at least, system configuration information is >> propigated between daemons mostly along the dbus, and the openwrt folk >> have implemented a ubus that is lighter weight, that communicates >> between dhcpv6, dns, dhcpv4 and other daemons. >> >> So what's needed is a clear delination of responsibilties for >> acquiring and pushing out changes to the underlying network >> architecture, and it doesn't matter what protocol on the wire those >> run over. >> >> 3) So far in dealing with highly dynamic ipv6, and poor interfaces to >> DNS in particular in the real world, I despise it and go back to >> wanting a /48 distributed with my house, or at least, some way to buy >> one from my ISP. >> >> 4) In my case at least the prefix distribution problem aint' problem >> 'cause I just ship /128s everywhere I need 'em with AHCP. >> >> /me ducks >> >> Yes, distributing prefixes is needed. >> >> 5) To finally get to your own point, there is no need to poll at the >> protocol level, the daemons on the responsible routers need be aware >> of changes and push them. Ideally there is some level of >> authentication involved, >> particularly in changes pushed like "forcibly retract this ipv6 prefix >> and use this one instead because my provider just changed me for no >> f-ing good reason") >> >> We've demonstrated that a protocol like AHCP can do that, (and nobody >> is suggesting that AHCP as currently defined is sufficient, it merely >> serves as a convenient counter-example to the >> embed-everything-in-the-routing protocol thread, that anybody can >> install and run, as it's been available in linux for 6+ years....) >> >> 6) A well defined set of TLVs and actions for border discovery, nat >> detection in ipv4, and carrying dns, ntp, and other core services is >> needed no matter how they are distributed. >> >> 7) I generally despair of this entire debate, and wish more people >> were writing code, doing experiments, and working inside the real >> world. I hate that this discussion has ratholed on the method of >> distribution, rather on than on "what configuration information needs >> to be propagated inside the home on zigbee, wifi, lte, moca, homeplug, >> in order to have grandma be able to get her pr0n and meds from her >> high-tech wheelchair. " >> >> me, for example, am observing how src/dst routing works in the real >> world, and am trying to improve it, deal with bcp38 and vpn >> technolgies, etc. There is a lot of work to be done to defeat in >> detail all the existing problems, and I argue strongly for trying >> stuff, iterating, and trying more stuff, until a viable >> standard for these problem emerges... >> >> ... and that, is probably the basic beef I have in modifying an >> existing routing protocol. Solving configuration distribution and >> border discovery, and nat detection, and core service distribution - >> needs a design small, flexible, and rapidly iterate-able, and >> *separate*, for these problems. >> >> I certainly wish we could foresee all problems in advance; we >> obviously can't (two years on this thread running), something flexible >> and iterate-able is needed. >> >>> _______________________________________________ >>> homenet mailing list >>> homenet@ietf.org >>> https://www.ietf.org/mailman/listinfo/homenet >>> >> >> >> --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html From jch@pps.univ-paris-diderot.fr Sun Feb 2 11:53:51 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 392DA1A00FF for ; Sun, 2 Feb 2014 11:53:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id geL9H1tiBFu6 for ; Sun, 2 Feb 2014 11:53:50 -0800 (PST) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) by ietfa.amsl.com (Postfix) with ESMTP id DCE701A00FE for ; Sun, 2 Feb 2014 11:53:49 -0800 (PST) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/46573) with ESMTP id s12JrhSC021873; Sun, 2 Feb 2014 20:53:43 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 153F96F2D2; Sun, 2 Feb 2014 20:53:43 +0100 (CET) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id DiT6GljuJ6vB; Sun, 2 Feb 2014 20:53:41 +0100 (CET) Received: from ijon.pps.jussieu.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 3A0FC6F2CD; Sun, 2 Feb 2014 20:53:41 +0100 (CET) Date: Sun, 02 Feb 2014 20:53:40 +0100 Message-ID: <871tzlmgu3.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Brian E Carpenter In-Reply-To: <52EDBEDA.1020208@gmail.com> References: <87iosy2tf4.wl%jch@pps.univ-paris-diderot.fr> <52EDBEDA.1020208@gmail.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Sun, 02 Feb 2014 20:53:43 +0100 (CET) X-Miltered: at korolev with ID 52EEA247.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 52EEA247.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 52EEA247.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Homenet protocol decisions X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Feb 2014 19:53:51 -0000 > I happen to have one in mind. It's discussed for the case of > carrier networks in > http://tools.ietf.org/html/draft-jiang-config-negotiation-ps-02 I've now read this draft. Section 2.4 says things that I never even considered, and I need to think it over. (In particular, functionality such as what you describe there would be marvelous for monitoring tools.) There's only one point that I disagree with. In Section 4 you say: Multi-party negotiations are too complicated to be modeled and there may be too many dependencies among the parties to converge efficiently. If I read you right, you're disallowing the familiar claim/defend scheme, where a node claims an address over multicast, and waits for other nodes to disagree. (The best-known case is probably that of DHCPv4, where implementations commonly make an ARP query before assigning an address, but there's no reason why this shouldn't be an intrinsic part of the configuration protocol.) -- Juliusz From mike@mtcc.com Sun Feb 2 11:58:10 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A5151A00F7 for ; Sun, 2 Feb 2014 11:58:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.637 X-Spam-Level: X-Spam-Status: No, score=-1.637 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cs-tJM9kazPU for ; Sun, 2 Feb 2014 11:58:09 -0800 (PST) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 7C3E31A00FF for ; Sun, 2 Feb 2014 11:58:09 -0800 (PST) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.7/8.14.7) with ESMTP id s12Jw50C024816 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sun, 2 Feb 2014 11:58:05 -0800 Message-ID: <52EEA34D.2070003@mtcc.com> Date: Sun, 02 Feb 2014 11:58:05 -0800 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: homenet@ietf.org References: <87bnyq2rhb.wl%jch@pps.univ-paris-diderot.fr> <52EE9559.6060406@gmail.com> In-Reply-To: <52EE9559.6060406@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Authentication-Results: mtcc.com; v=0.1; dkim-asp=all-fail header.From=mike@mtcc.com Subject: Re: [homenet] Homenet protocol decisions X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Feb 2014 19:58:10 -0000 On 02/02/2014 10:58 AM, Brian E Carpenter wrote: > > Because routing protocol authors are generally hostile to adding > what is effectively dhcp-like support to their protocols and daemons? > I think there's a reason for that "hostility", which is that in some > sense everything other than routing is less fundamental, and we need > to protect routing from the rest by isolating it. If routing fails, > nothing else can work, after all. So there's a tendency to keep > the routing protocols "pure". > > However, the great thing about routing protocols is that they really > are very close to autonomic, and we need that instead of traditional > top-down configuration. Despite the protests, I detect hints of > top-downness in many of the messages on this thread. Apart from > external routes and available global prefixes, what else *needs* > to be top-down in a homenet? > > If you're worried about isolation, you could always run the same routing protocol -- modified to carry your payloads -- on, say, a different port and modify the daemon to not touch the fib. Mike From alexandru.petrescu@gmail.com Mon Feb 3 01:04:59 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 383A31A0192 for ; Mon, 3 Feb 2014 01:04:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.383 X-Spam-Level: X-Spam-Status: No, score=-4.383 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, J_CHICKENPOX_42=0.6, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zUWgS1gV14dX for ; Mon, 3 Feb 2014 01:04:57 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id C6FDA1A0170 for ; Mon, 3 Feb 2014 01:04:56 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s1394pD5010361 for ; Mon, 3 Feb 2014 10:04:51 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 633C120219F for ; Mon, 3 Feb 2014 10:05:08 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 5B95320216D for ; Mon, 3 Feb 2014 10:05:08 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s1394jb5030532 for ; Mon, 3 Feb 2014 10:04:51 +0100 Message-ID: <52EF5BAD.3000907@gmail.com> Date: Mon, 03 Feb 2014 10:04:45 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: homenet@ietf.org References: <87bnyq2rhb.wl%jch@pps.univ-paris-diderot.fr> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [homenet] Homenet protocol decisions X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 09:04:59 -0000 Le 02/02/2014 17:47, Acee Lindem a écrit : > I agree. I disagree questioning what happens when the routing protocol finds out that even though the delegation protocol things everything is ok and addresses were delegated justfine the network becomes partitioned. First, I would try to understand what is meant by partitioned network. I have heard this term in the MANET/AUTOCONF discussion as well; there it was high level just to give a feeling about how a network would become disconnected. But less of a real experience. Then, a delegation protocol (DHCP-PD, see the other threat), is guided by a pre-configured database. That database should be in sync with the routing protocol pre-configured database. If these two files are not sync'ed then it's the planners fault. Or otherwise automatic means exist to make them be in sync. Also, plugging the DHCP prefix delegation protocol into the routing protocol would be a two-way process, not just one=way: DHCP-PD would inform the routing protocol daemon about the allocation, subsequently this latter would update some local routes; but also - if the routing protocol finds there are some loops then it reports an error to the DHCP PD daemon. One should also take into account that a routing protocol doing prefix delegation at the same time as DHCP-PD (without knowledge one of the other) is probably goign to become a source of contention. > Also, since we already have to bootstrap an auto-configuring routing > protocol, why not leverage this work to distribute other > information? I do not disagree with this. I think it is meaningful direction as well. Alex > Acee > > On Feb 2, 2014, at 12:45 AM, Lorenzo Colitti wrote: > >> On Sat, Feb 1, 2014 at 6:11 PM, Juliusz Chroboczek >> > > wrote: >> >>> And what happens when the routing protocol finds out that, even >> though the >>> delegation protocol thinks everything is OK and addresses were >> delegated just >>> fine, the network is now partitioned? How do you reassign >> addresses in that >>> case? >> >> I fail to see how this particular functionality requires merging >> the two protocols. If a link is partitioned, you need to time-out >> the address assignments made by the now unreachable router. Whether >> they are timed out by the routing protocol or by a separate >> configuration protocol is pretty much an implementation detail, >> isn't it? >> >> >> The routing protocol knows that the network is partitioned because >> that's what it does. How is the configuration distribution protocol >> going to know that? Either you couple it to the routing protocol, >> or you have it poll to see if things have changed (inefficient >> and/or slow to notice changes). Why would you do the latter? > > > > _______________________________________________ homenet mailing list > homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet > From otroan@employees.org Mon Feb 3 01:06:00 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F222C1A0198 for ; Mon, 3 Feb 2014 01:05:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.635 X-Spam-Level: X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EDu8hgD9OpnF for ; Mon, 3 Feb 2014 01:05:58 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id F1FD81A0170 for ; Mon, 3 Feb 2014 01:05:57 -0800 (PST) X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAP1a71KQ/khN/2dsb2JhbABZgwy/J4EDFnSCJQEBBAF5BQsLRlcGiBAIzQ8XjjJXB4MkgRQEkD+EA5YJgy47gS0 X-IronPort-AV: E=Sophos;i="4.95,771,1384300800"; d="asc'?scan'208";a="4573667" Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-1.cisco.com with ESMTP; 03 Feb 2014 09:05:52 +0000 Received: from dhcp-lys01-vla250-10-147-113-220.cisco.com (dhcp-lys01-vla250-10-147-113-220.cisco.com [10.147.113.220]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s1395o5Z014416 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 3 Feb 2014 09:05:51 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_03B2234A-F3EF-4674-AAD9-C58F79E71BE6"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ole Troan In-Reply-To: Date: Mon, 3 Feb 2014 10:05:49 +0100 Message-Id: <09FAB9C1-3ADB-46D9-87EF-B1F1F1353F74@employees.org> References: <87bnyq2rhb.wl%jch@pps.univ-paris-diderot.fr> To: Dave Taht X-Mailer: Apple Mail (2.1827) Cc: Acee Lindem , Lorenzo Colitti , "homenet@ietf.org Group" , Juliusz Chroboczek Subject: Re: [homenet] Homenet protocol decisions X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 09:06:00 -0000 --Apple-Mail=_03B2234A-F3EF-4674-AAD9-C58F79E71BE6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 > 7) I generally despair of this entire debate, and wish more people > were writing code, doing experiments, and working inside the real > world. I hate that this discussion has ratholed on the method of > distribution, rather on than on "what configuration information needs > to be propagated inside the home on zigbee, wifi, lte, moca, homeplug, > in order to have grandma be able to get her pr0n and meds from her > high-tech wheelchair. " apart from the sentence making it appear that "configuration = information" hinges on data-link type, I think you make an important = point. what information needs to be propagated in the home? since this is the homenet working group, we limit ourselves to getting = the network layer functional. that in my mind is: addressing, unicast routing, service discovery, = external naming, other host configuration, and time. unicast routing: - internal routes (assigned /64s and ULA) - SADR routes for PD prefixes (either explicit SADR or implied as part of prefix assignment) - More specific external routes (learnt via RFC4191 or other = configuration) requires explicit SADR addressing: - PD prefixes - ULA prefixes - whatever assigned prefixes required for the prefix assignment = algorithm to function - meta data associated with prefixes (SAS/DAS policy, colour) service discovery: - DNS zones for the bootstrapping the mDNS scheme external naming: - I don't see how we can make this zero-conf. each border router could = run hidden primaries for the reverse zone. if you get forward zones from the ISPs, then applications could = update each of those primaries using DNS update. assuming we can bootstrap security. if the home has a vanity name, = then the hidden primaries must run on some well known address in the home, and there has to be some = agreement with either ISP or someone else to run secondaries. other host configuration: - this is information learnt from external connections, homenet = defaults and configuration provided by the user. basically externally learn from RA/DHCP, and passed transparently = through the homenet, for homenet routers to propagate to hosts using DHCP/RA - DNS recursive resolvers - DNS server selection policy - SAS/DAS policy - NTP servers - whatever else is required for configuration of the network layer we could put these into three different classes: 1) addressing / routing 2) configuration information for the homenet routers 3) configuration information for hosts (that the homenet passes transparently from some source to hosts) addressing and routing are inherently tided together. the home network = is quite useless without either of them functioning. if we look at a routing protocol as just a distributed database, it = might not matter what we put into it, although it makes my tummy churn = to think about embedding DHCP options into OSPF. ;-) cheers, Ole =20 --Apple-Mail=_03B2234A-F3EF-4674-AAD9-C58F79E71BE6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJS71vtAAoJEFuJXizso86gIuYIAJ8Ts5ksWviLM6yOKjoJZ0lZ n/wVHIduF0pVZf3iHiBv9u0E3QD6dn20njjSG5CQwWMecIhUjEX8uJxQFYfpCFlI RQRb+QzuADnJlMLvoiwdBUlHbTGPudYf5/D4bsI1MQ9NHn6ls5ynGYprLZVWCzYg +VbVfkdkoIOzJ1AfMh4vsCjtbNBD62OGbFIMKNJhITTFL8gvdmi4Q4cNH4+t8ac7 zoDmhTkzkcWciny47ycOjrtMkLpsga2N0maBxO2r/efz+YeOKIdRW/QUT8UCwI3O rjf1cFgn7MYxKqnwGnhkBjpg4A6GRGUaFNt56QC/jgv90vm58TU7nEHRsTMyicU= =dDsn -----END PGP SIGNATURE----- --Apple-Mail=_03B2234A-F3EF-4674-AAD9-C58F79E71BE6-- From alexandru.petrescu@gmail.com Mon Feb 3 05:50:25 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79DC31A0219 for ; Mon, 3 Feb 2014 05:50:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HkNAs1Uv-47P for ; Mon, 3 Feb 2014 05:50:23 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id E86EE1AD62B for ; Mon, 3 Feb 2014 04:51:27 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s13CpMpm012363; Mon, 3 Feb 2014 13:51:22 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id DD73A202312; Mon, 3 Feb 2014 13:51:39 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id CF895202279; Mon, 3 Feb 2014 13:51:39 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s13Cp9cc028333; Mon, 3 Feb 2014 13:51:22 +0100 Message-ID: <52EF90BD.4070701@gmail.com> Date: Mon, 03 Feb 2014 13:51:09 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Ole Troan References: <52EA3032.3050703@gmail.com> <52EA3361.1010501@gmail.com> <2EB6289E-C7FD-481F-99F9-E35730245943@employees.org> <52EA442D.3020707@gmail.com> <52EA47AA.90302@gmail.com> <1FE00515-A7AD-4C48-A7F2-63BA8696D818@darou.fr> <52EA4BB1.9010607@gmail.com> <2922CC94-540D-4215-899B-4722BD1C5EBC@employees.org> In-Reply-To: <2922CC94-540D-4215-899B-4722BD1C5EBC@employees.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "homenet@ietf.org Group" , Pierre Pfister Subject: Re: [homenet] DHCP PD X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 13:50:25 -0000 Le 30/01/2014 14:03, Ole Troan a écrit : > Alex, > > changing the thread since this seems to diverge from getting answers to the questions I asked. > > cheers, > Ole > > > On 30 Jan 2014, at 13:55 , Alexandru Petrescu wrote: > >> Pierre, >> >> Thanks for the reply. >> >> Le 30/01/2014 13:46, Pierre Pfister a écrit : >>> >>> Le 30 janv. 2014 à 13:38, Alexandru Petrescu >>> a écrit : >>> >>>> Le 30/01/2014 13:28, Ole Troan a écrit : >>>>>>>> Could it be separate (existing) protocol? >>>>>>> >>>>>>> if one had existed, sure. requirements from homenet-arch (I >>>>>>> might have missed some): - must support multi-homing - each >>>>>>> link should be assigned a stable prefix - efficient >>>>>>> allocation of prefixes - should support both IPv4 and IPv6 >>>>>> >>>>>> I meant this: >>>>>> >>>>>> loosely coupled ---- separate (existing DHCPv6-PD) protocol >>>>>> triggering route updates to the routing protocol. >>>>> >>>>> yes, DHCP PD comes up as a proposed solution quite frequently. I >>>>> just don't see how you can make DHCP PD fulfill the >>>>> requirements. >>>> >>>> Well it does support multi-homing (Server allocates things to as >>>> many interfaces as needed), each link can be assigned a stable >>>> prefix (provided it triggers updates to the Routing protocol), the >>>> allocation is efficient (Server maintains dynamic databases, >>>> leases) and it supports both IPv4 ('IPv4 subnet allocation' >>>> RFC6656, DHCP transition et alia), and IPv6. >>>> >>>> I miss something? >>> >>> Well, in some cases DHCP seems to work, but not when you start >>> imagining multi-homed networks with multiple routers. Or maybe you >>> can tell me how to solve this situation with DHCP: >>> >>> You have ISP1 connected with Router 1. ISP2 connected with Router 2. >>> Router 1, Router 2, and a third Router (Router 3), are connected on >>> the same link. ISP1 is delegated the prefix A/56 to Router 1. ISP2 >>> is delegating the prefix B/56 to Router 2. >>> >>> A host is connected behind Router 3. >> >> Bear with me for a moment... is this topology what you meant? >> >> >> ISP1 ISP2 >> | | >> +-------+ +-------+ >> |Router1|A/56 |Router2|B/56 >> +-------+ +-------+ >> | | >> --+-------+----------+-- >> | >> | >> +-------+ >> |Router3| >> +-------+ >> | >> +----+ >> |Host|(how can it get an address from A, and from B) >> +----+ In this setting the Router3 could run two DHCPRelay processes, and Router1 and 2 would be Servers. This would allow Host to obtain an address from each (==multi-homed). Alex >> >> >>> How can it get addresses from both prefixes ? >> >> Before I try to figure it out - is the above topology what is meant? Something I misplaced? >> >> Alex >> >>> >>> Cheers, >>> >>> Pierre >>> >>> >>>> >>>> Alex >>>> >>>>> >>>>> cheers, Ole >>>>> >>>> >>>> >>>> _______________________________________________ homenet mailing >>>> list homenet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/homenet > From Ray.Bellis@nominet.org.uk Mon Feb 3 06:14:56 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 361C81A00CC for ; Mon, 3 Feb 2014 06:14:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.835 X-Spam-Level: X-Spam-Status: No, score=-4.835 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IlZpHcegf6gq for ; Mon, 3 Feb 2014 06:14:54 -0800 (PST) Received: from mx1.nominet.org.uk (mx1.nominet.org.uk [213.248.242.48]) by ietfa.amsl.com (Postfix) with ESMTP id 450B41A01E2 for ; Mon, 3 Feb 2014 06:11:14 -0800 (PST) DomainKey-Signature: s=main2.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:X-IPAS-Result:Received:Received:From:To:CC: Subject:Thread-Topic:Thread-Index:Date:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: Content-Type:Content-ID:Content-Transfer-Encoding: MIME-Version; b=P9BrffIWVf1bgadtJAXPu3+sFpevvA9ShapS91xPz1ZEpwNR9acfshBA pwrBrOdZofvJfTDH71by72a6XTyqSlkv46i8x3rcnG+YAVLvJ1kPwjlaS ZNX00nIS3RqaO2BHp6/9y82x6Qdw1TK3R/amlnRLzwGutFKt4u8nWQCFh iqUTNhjfvlAaRW0mi6fRKpcFe9H+lJgThqN2zhZnSdEb4eQ79k24+FRci S3Nw2HYsEMgEyAe1u6umIS7whnhs1; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=@nominet.org.uk; q=dns/txt; s=main2.dkim.nominet.selector; t=1391436674; x=1422972674; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=STN5bOQnuxujnY2sP/NFk/Pv6w3cXza1CjSnRaTFJGw=; b=yQoBXAnKXGWBb3O3cSZu/z3BqYUPTXdvvu8/np3XmmWxWBYNg1qbaEBQ Ich5PvOck4Z0AXqH5toSKeIbTaS51EhCbcySXejE7RBQBBJ3M/viYglIG gzGeQfCzm6TJjJC/JrcoZlDYbfDkkxx1oPqAVv1oYlLxgIahJWFqA2knX lgXGB2xogp834gicsvqppdfKjW4R0cJ7Pkx3Vwjq3AonXo11bLrgsTFbu BAMf8OA8tqsozApK5aDvEPpdNkZch; X-IronPort-AV: E=Sophos;i="4.95,772,1384300800"; d="scan'208";a="7319596" X-IPAS-Result: AhwFABCj71LV+MWR/2dsb2JhbABZgmshgQ++CIEIFnSCJQEBAQECAVMmBQsCAQgiJCERJQIEDgUIh2kDCQkDww8NiTMXjHOBYwIxB4MkgRQEiRGNLY5KhUODLYIq Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx1.nominet.org.uk with ESMTP; 03 Feb 2014 14:11:13 +0000 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%17]) with mapi id 14.02.0318.004; Mon, 3 Feb 2014 14:11:12 +0000 From: Ray Bellis To: Alexandru Petrescu Thread-Topic: [homenet] DHCP PD Thread-Index: AQHPIOcHqXqfPkUHVUiNCUDE4k76BZqjkcUA Date: Mon, 3 Feb 2014 14:11:11 +0000 Message-ID: <18C8BE29C547CC4DBBCF3C4F0B8EC1780608ED@wds-exc1.okna.nominet.org.uk> References: <52EA3032.3050703@gmail.com> <52EA3361.1010501@gmail.com> <2EB6289E-C7FD-481F-99F9-E35730245943@employees.org> <52EA442D.3020707@gmail.com> <52EA47AA.90302@gmail.com> <1FE00515-A7AD-4C48-A7F2-63BA8696D818@darou.fr> <52EA4BB1.9010607@gmail.com> <2922CC94-540D-4215-899B-4722BD1C5EBC@employees.org> <52EF90BD.4070701@gmail.com> In-Reply-To: <52EF90BD.4070701@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.1] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <610F965202A7414DBE182DBC6D26242E@okna.nominet.org.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ole Troan , Pierre Pfister , "homenet@ietf.org Group" Subject: Re: [homenet] DHCP PD X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 14:14:56 -0000 On 3 Feb 2014, at 12:51, Alexandru Petrescu = wrote: > In this setting the Router3 could run two DHCPRelay processes, and Router= 1 and 2 would be Servers. >=20 > This would allow Host to obtain an address from each (=3D=3Dmulti-homed). It could, but assume that Router3 doesn't yet know anything about the upstr= eam topology. Ray (no hat)= From mcr@sandelman.ca Mon Feb 3 06:19:09 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFFD51A00C7 for ; Mon, 3 Feb 2014 06:19:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.019 X-Spam-Level: * X-Spam-Status: No, score=1.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665, T_TVD_MIME_NO_HEADERS=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YMyIeyBIEUV5 for ; Mon, 3 Feb 2014 06:19:07 -0800 (PST) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 26CDF1A00A3 for ; Mon, 3 Feb 2014 06:19:07 -0800 (PST) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 0FD5C20032; Mon, 3 Feb 2014 10:35:57 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id DE6B864656; Mon, 3 Feb 2014 09:19:04 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id CFBAC63AD7; Mon, 3 Feb 2014 09:19:04 -0500 (EST) From: Michael Richardson To: "homenet\@ietf.org Group" In-Reply-To: <52EDBEDA.1020208@gmail.com> References: <87iosy2tf4.wl%jch@pps.univ-paris-diderot.fr> <52EDBEDA.1020208@gmail.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: Juliusz Chroboczek Subject: Re: [homenet] Homenet protocol decisions X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 14:19:09 -0000 --=-=-= Brian E Carpenter wrote: > You (and others) who speak of a "Homenet Configuration > Protocol" seem to be making an assumption which is far from > clear to me. That assumption is that config parameters in a homenet > will come in some sense top-down from a higher level source of > authority. I'm not sure that he is making this assumption. There are clearly sources of authority for various things: the border router(s) know about the services from the ISP(s) they are connected to. I might also say, "the printer knows that it is a printer", but that already a solved problem. The key thing is that some component knows that the local zone is carpenterhouse.example.com, and may let the printer know that, so that it can advertise that name into the right places. > I think we need a completely different approach. Just by chance, > I happen to have one in mind. It's discussed for the case of > carrier networks in > http://tools.ietf.org/html/draft-jiang-config-negotiation-ps-02 > I believe that exactly the same approach is needed for homenets. I read the beginnging of the document, and it seems in sync with with Juliuz is actually talking about. I did not find enough motivation in the document for what is desired. I am also skeptical that there are significant configuration things in the homenet which ultimately need to share fate with connectivity. I am most worried that we really have no process here to make a decision. -- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUu+lVoqHRg3pndX9AQJvBQQA2ttVkw5wKFuhYS9YcV8F93owuf8Vl4di hq7/bLpnqsbB1Ytvg+7CLjh4X/EMsLLhEr4idz37kU1PP+V53J5mjdk39ObmKKQk DG3/k1eSS9QdcP45RA6JOSVzKts8RASLewDH7DZ/ZBqnsUHM0Kaw/TjXNZNS6qdS M2ytBjRWv44= =TlEX -----END PGP SIGNATURE----- --=-=-=-- From alexandru.petrescu@gmail.com Mon Feb 3 06:24:10 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C5F11A0029 for ; Mon, 3 Feb 2014 06:24:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id olFcksQPWL5N for ; Mon, 3 Feb 2014 06:24:09 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE951A0014 for ; Mon, 3 Feb 2014 06:24:08 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s13EO4R4014236; Mon, 3 Feb 2014 15:24:05 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 45B912024DF; Mon, 3 Feb 2014 15:24:22 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 2C2E42023A1; Mon, 3 Feb 2014 15:24:22 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s13EO21P030716; Mon, 3 Feb 2014 15:24:04 +0100 Message-ID: <52EFA682.4040906@gmail.com> Date: Mon, 03 Feb 2014 15:24:02 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Ray Bellis References: <52EA3032.3050703@gmail.com> <52EA3361.1010501@gmail.com> <2EB6289E-C7FD-481F-99F9-E35730245943@employees.org> <52EA442D.3020707@gmail.com> <52EA47AA.90302@gmail.com> <1FE00515-A7AD-4C48-A7F2-63BA8696D818@darou.fr> <52EA4BB1.9010607@gmail.com> <2922CC94-540D-4215-899B-4722BD1C5EBC@employees.org> <52EF90BD.4070701@gmail.com> <18C8BE29C547CC4DBBCF3C4F0B8EC1780608ED@wds-exc1.okna.nominet.org.uk> In-Reply-To: <18C8BE29C547CC4DBBCF3C4F0B8EC1780608ED@wds-exc1.okna.nominet.org.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Ole Troan , Pierre Pfister , "homenet@ietf.org Group" Subject: Re: [homenet] DHCP PD X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 14:24:10 -0000 Le 03/02/2014 15:11, Ray Bellis a écrit : > > On 3 Feb 2014, at 12:51, Alexandru Petrescu > wrote: > >> In this setting the Router3 could run two DHCPRelay processes, and >> Router1 and 2 would be Servers. >> >> This would allow Host to obtain an address from each >> (==multi-homed). > > It could, but assume that Router3 doesn't yet know anything about > the upstream topology. Right, so it would need to discover it - a DHCP Server discovery mechanism performed by Relay. I doubt the multi-homing requirement as such would be a criterion to simply discard DHCP-PD. (w/o comparing alternatives, I would say that routing protocols also need something like a discovery procedure when they dont know yet their upstream). Alex > > Ray (no hat) > From mcr@sandelman.ca Mon Feb 3 06:27:31 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2CC51A0035 for ; Mon, 3 Feb 2014 06:27:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.707 X-Spam-Level: *** X-Spam-Status: No, score=3.707 tagged_above=-999 required=5 tests=[FH_RELAY_NODNS=1.451, RDNS_NONE=1.274, SPF_SOFTFAIL=0.972, T_TVD_MIME_NO_HEADERS=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t_vjOH27sOu0 for ; Mon, 3 Feb 2014 06:27:30 -0800 (PST) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id A170A1A002A for ; Mon, 3 Feb 2014 06:27:30 -0800 (PST) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 57BCD20033; Mon, 3 Feb 2014 10:44:22 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 948F564656; Mon, 3 Feb 2014 09:27:30 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 856CA63AD7; Mon, 3 Feb 2014 09:27:30 -0500 (EST) From: Michael Richardson To: "homenet\@ietf.org Group" , Juliusz Chroboczek In-Reply-To: <87y51tmopr.wl%jch@pps.univ-paris-diderot.fr> References: <87bnyq2rhb.wl%jch@pps.univ-paris-diderot.fr> <87y51tmopr.wl%jch@pps.univ-paris-diderot.fr> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: Acee Lindem Subject: Re: [homenet] Homenet protocol decisions X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 14:27:31 -0000 --=-=-= Juliusz Chroboczek wrote: > As usual, it's a tradeoff, and the choice of tradeoff is dependent on > one's background. > Those of us who come from the Free Software chaos will prefer small, > self-contained protocols that can be implemented by small, loosely > coupled groups of developers, and that communicate through well- > defined, stable APIs. Yes, I've lived in this space for 20+ years. In that space, we still don't have a DHCP client which can sensibly interact with an 1X supplicant in order to get me on a network which has a working layer-3 uplink, even though the layer-2 signal strength is not the strongest. (I call then "NOTworks", an AP sitting somewhere with a broken DSL link) NetworkManager and its equivalent in Android is closest we have gotten, and there are still significant issues: they are getting better, but it hasn't been fun. And it's not the size of the protocol that really matters. One problem that the free software chaos suffers from is that much of the tools that we have (quagga, ISC DHCP, for instance) are designed by "big organizations" for "big organizations". > Those who come from large, well-managed, centralised organisations > will prefer large protocols, and won't want to bother with the tricky > job of defining stable interfaces between loosely coupled software > components. I think that are significantly overstating this situation. Big organizations are seldom well organized or well managed, and they hate forklift upgrades, so they actually prefer small incremental additions as well. -- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUu+nUIqHRg3pndX9AQJzVgP8CHhFjcuSILrLiX5yTw8aaAsFTBwXlUxi 8uB1Bvy8TBUaMpGGoeRCylzha7XUOrVJ3xp4dDzJ4AVVW9yeouEv79+isKvcR98+ uvRxf1sZr4bAiYx3E/+P+XhEoBNgMBkPK5mooe7+MQ1hidFpoCuI593qN6QuomeG 4SEskOrbby4= =N8ay -----END PGP SIGNATURE----- --=-=-=-- From SRS0=Tsjg=XI=darou.fr=pierre.pfister@bounces.m4x.org Mon Feb 3 06:39:18 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 234111A00F4 for ; Mon, 3 Feb 2014 06:39:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d22nAmIk9lz7 for ; Mon, 3 Feb 2014 06:39:16 -0800 (PST) Received: from mx1.polytechnique.org (mx1.polytechnique.org [129.104.30.34]) by ietfa.amsl.com (Postfix) with ESMTP id CBB1F1A002B for ; Mon, 3 Feb 2014 06:39:15 -0800 (PST) Received: from ams3-vpn-dhcp3640.cisco.com (173-38-208-169.cisco.com [173.38.208.169]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ssl.polytechnique.org (Postfix) with ESMTPSA id 91156140912F6; Mon, 3 Feb 2014 15:39:12 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Pierre Pfister In-Reply-To: <18C8BE29C547CC4DBBCF3C4F0B8EC1780608ED@wds-exc1.okna.nominet.org.uk> Date: Mon, 3 Feb 2014 07:39:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8B52F0C3-EB5A-48D1-9596-52302F6A4A3C@darou.fr> References: <52EA3032.3050703@gmail.com> <52EA3361.1010501@gmail.com> <2EB6289E-C7FD-481F-99F9-E35730245943@employees.org> <52EA442D.3020707@gmail.com> <52EA47AA.90302@gmail.com> <1FE00515-A7AD-4C48-A7F2-63BA8696D818@darou.fr> <52EA4BB1.9010607@gmail.com> <2922CC94-540D-4215-899B-4722BD1C5EBC@employees.org> <52EF90BD.4070701@gmail.com> <18C8BE29C547CC4DBBCF3C4F0B8EC1780608ED@wds-exc1.okna.nominet.org.uk> To: Ray Bellis X-Mailer: Apple Mail (2.1827) X-AV-Checked: ClamAV using ClamSMTP at svoboda.polytechnique.org (Mon Feb 3 15:39:14 2014 +0100 (CET)) Cc: Alexandru Petrescu , "homenet@ietf.org Group" , Ole Troan Subject: Re: [homenet] DHCP PD X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 14:40:06 -0000 Le 3 f=E9vr. 2014 =E0 07:11, Ray Bellis a = =E9crit : >=20 > On 3 Feb 2014, at 12:51, Alexandru Petrescu = wrote: >=20 >> In this setting the Router3 could run two DHCPRelay processes, and = Router1 and 2 would be Servers. >>=20 >> This would allow Host to obtain an address from each (=3D=3Dmulti-homed= ). I=92m not sure DHCP Relaying was intended to work with different DHCP = servers. In any case, DHCP client was not. We can=92t ask routers to relay DHCP from whatever DHCP server they = obtain something from. In the case Router 2 has the same problem as = router 3, we would have two relays ? And so on ? It would require a = discovery mechanism and only the very first owner of a prefix would = provide the addresses. In which case it would probably need knowledge of = the network. And suddenly it starts looking like a different = configuration protocol. At least it doesn=92t look like how DHCP was = designed first. Over more, if you put a host instead of Router 3, we would need the host = to have multiple DHCP server. So it not only is inefficient in terms of = addressing, but requires changes to the hosts=85 And assuming multiple = DHCP server is not, in my mind, a small change. Pierre >=20 > It could, but assume that Router3 doesn't yet know anything about the = upstream topology. >=20 > Ray (no hat) > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From mellon@fugue.com Mon Feb 3 06:51:48 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC00D1A00EA for ; Mon, 3 Feb 2014 06:51:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.536 X-Spam-Level: X-Spam-Status: No, score=-0.536 tagged_above=-999 required=5 tests=[RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KdGYpDYjMjNv for ; Mon, 3 Feb 2014 06:51:47 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 0D7A21A0131 for ; Mon, 3 Feb 2014 06:51:41 -0800 (PST) Received: from [10.0.10.40] (c-174-62-147-182.hsd1.nh.comcast.net [174.62.147.182]) by toccata.fugue.com (Postfix) with ESMTPSA id 0CB0F23802F8; Mon, 3 Feb 2014 09:51:37 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ted Lemon In-Reply-To: <8B52F0C3-EB5A-48D1-9596-52302F6A4A3C@darou.fr> Date: Mon, 3 Feb 2014 09:51:35 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <8FA52BBD-9A61-4795-9BA3-AB8B0A63EB98@fugue.com> References: <52EA3032.3050703@gmail.com> <52EA3361.1010501@gmail.com> <2EB6289E-C7FD-481F-99F9-E35730245943@employees.org> <52EA442D.3020707@gmail.com> <52EA47AA.90302@gmail.com> <1FE00515-A7AD-4C48-A7F2-63BA8696D818@darou.fr> <52EA4BB1.9010607@gmail.com> <2922CC94-540D-4215-899B-4722BD1C5EBC@employees.org> <52EF90BD.4070701@gmail.com> <18C8BE29C547CC4DBBCF3C4F0B8EC1780608ED@wds-exc1.okna.nominet.org.uk> <8B52F0C3-EB5A-48D1-9596-52302F6A4A3C@darou.fr> To: Pierre Pfister X-Mailer: Apple Mail (2.1827) Cc: Ray Bellis , Alexandru Petrescu , "homenet@ietf.org Group" , Ole Troan Subject: Re: [homenet] DHCP PD X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 14:51:49 -0000 On Feb 3, 2014, at 9:39 AM, Pierre Pfister = wrote: > I=92m not sure DHCP Relaying was intended to work with different DHCP = servers. In any case, DHCP client was not. This is not actually true. RFC 3315 was written with the clear = anticipation of the possibility that a DHCP client might talk to = multiple DHCP servers. It doesn't specifically require this behavior, = and it doesn't always make sense, but if you have two managed prefixes = on a wire, I would expect a DHCP client to try to configure both of = them, and if two DHCP servers each manage one of the prefixes, I would = expect the DHCP client to wind up getting configurations from two = servers. It may be that we weren't clear enough on this point, but that was = definitely an anticipated use case. From mcr@sandelman.ca Mon Feb 3 07:00:12 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F2201A00F4 for ; Mon, 3 Feb 2014 07:00:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.707 X-Spam-Level: *** X-Spam-Status: No, score=3.707 tagged_above=-999 required=5 tests=[FH_RELAY_NODNS=1.451, RDNS_NONE=1.274, SPF_SOFTFAIL=0.972, T_TVD_MIME_NO_HEADERS=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i5XtjDtNvFzQ for ; Mon, 3 Feb 2014 07:00:11 -0800 (PST) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 47D581A00DC for ; Mon, 3 Feb 2014 07:00:11 -0800 (PST) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 1484920032 for ; Mon, 3 Feb 2014 11:17:02 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 3A6B264656; Mon, 3 Feb 2014 10:00:10 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 2802D63AD7 for ; Mon, 3 Feb 2014 10:00:10 -0500 (EST) From: Michael Richardson to: "homenet\@ietf.org Group" In-Reply-To: <32165.1391437144@sandelman.ca> References: <87iosy2tf4.wl%jch@pps.univ-paris-diderot.fr> <52EDBEDA.1020208@gmail.com> <32165.1391437144@sandelman.ca> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Subject: Re: [homenet] Homenet protocol decisions X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 15:00:12 -0000 --=-=-= Michael Richardson wrote: > I am also skeptical that there are significant configuration things in the > homenet which ultimately need to share fate with connectivity. Let me try again: I am also skeptical that there are significant configuration things in the homenet which *do not* ultimately need to share fate with connectivity. -- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUu+u94qHRg3pndX9AQLa0gP/WEm5H5oPx7CaNup2PvIFXlZ/FyJJ1MJ5 S0Wu+Dm9GPWdv5ORYE/xBMAClauw8Qk8837F7Lyqw2/9PFdi0lF6KAIBTfRxVhZq kAVECApKPPAs47twoJLGVjzlkw05LyUQJGehgON0QH4zEjGLVagL/IX1t0rib6Qm XNRBVe0XKU4= =cVdy -----END PGP SIGNATURE----- --=-=-=-- From mellon@fugue.com Mon Feb 3 07:29:57 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 391B91A0165 for ; Mon, 3 Feb 2014 07:29:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9BU1NzZuXx_f for ; Mon, 3 Feb 2014 07:29:56 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 2678E1A0158 for ; Mon, 3 Feb 2014 07:29:56 -0800 (PST) Received: from [10.0.10.40] (c-174-62-147-182.hsd1.nh.comcast.net [174.62.147.182]) by toccata.fugue.com (Postfix) with ESMTPSA id B1C6123802F8; Mon, 3 Feb 2014 10:29:54 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ted Lemon In-Reply-To: <9109.1391439610@sandelman.ca> Date: Mon, 3 Feb 2014 10:29:52 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87iosy2tf4.wl%jch@pps.univ-paris-diderot.fr> <52EDBEDA.1020208@gmail.com> <32165.1391437144@sandelman.ca> <9109.1391439610@sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1827) Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Homenet protocol decisions X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 15:29:57 -0000 On Feb 3, 2014, at 10:00 AM, Michael Richardson = wrote: > I am also skeptical that there are significant configuration things in = the > homenet which *do not* ultimately need to share fate with = connectivity. ULA seems like an obvious example. From lorenzo@google.com Mon Feb 3 11:06:41 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A6821A0200 for ; Mon, 3 Feb 2014 11:06:41 -0800 (PST) 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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IMQG9mtzAnHC for ; Mon, 3 Feb 2014 11:06:40 -0800 (PST) Received: from mail-qa0-x22e.google.com (mail-qa0-x22e.google.com [IPv6:2607:f8b0:400d:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 605BE1A0202 for ; Mon, 3 Feb 2014 11:06:39 -0800 (PST) Received: by mail-qa0-f46.google.com with SMTP id ii20so10624866qab.33 for ; Mon, 03 Feb 2014 11:06:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=pVOR8Xk4u0V0vyHFEWGIOPEz/jGIPEbf7mQKBfNBDeM=; b=Z9Zx4Ra3oPApA+WkWgcKGO+1AJ60yK8+Y/KQwygFDwx/Qt4wWaCKm1E19Sjl/D5fh6 abHHYobd56gBPOCI0ubkvubPAyOFytRa1oDsSeOlmpL6hPhntOGHqYowpI9+xO23FP9/ 6gHnfo3XSid96dSIzV3NTKqoEf6PFAmR+pZ2aEvzdiHIXBq9YlBMAS9vFmT1qAZKEQNA Xg7wQqg7hsLWXjUx64+SNg8teHfMqMjFYAH7XE89YiTDzVsRaTJSaru/sruD1GaCfqXK 1rBz0zSRRoOK733F4Mb6Z9DtXM2M7AYrvX9E37//gLXXZMaqWAgPB6UA7tFTv/Mpjdad fTXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=pVOR8Xk4u0V0vyHFEWGIOPEz/jGIPEbf7mQKBfNBDeM=; b=GMNaDglxwZc5huGa8ufknW9RHC3DJxCMOqb5uWHnnhjuaXPxe95QBwiQvTeyOmSs/5 mwu40lsdw2GEYXZ9akAHo7NL4JgBBUpANf9qBUeowvopgk9tDhfqd5kie7LmVfdF1q3l 5dGW5uNRdu00GUvhXr109s8Y8hfzs2/L9EhEivsevNy6LUS9FxiCYVoogQAge9nftNAP hS8Esvhh1DK5/mTggci4NksgmNm2bXLEmbfyZOkkChRHd43qNsCcr9QOGwybIdA4Au2n 5qEwNxVBh/IgEN6CQmnjUg2Jlw7BgYYKKeLhlrrJf8/KW1BWoZfqsbnh2HROOXX+VBpw 6E4Q== X-Gm-Message-State: ALoCoQlDwHmCelKRy7pGGtM2zaQk2d3NhYbm4uINv4iIhhBCeoDq2ftRCao5mVFcAdEywV1dPN60AyRek9BLpMfWttI2YJR5C2KdAqUCBVnLPX/w2j0omeqjcfiPwxyekiWSjlL4kidPnaDpbd19k87nEH4G70EKYcZdl2J866Sg1olmdroPu3ae3OefLstmZXw98NXs1KcE X-Received: by 10.224.160.195 with SMTP id o3mr8684905qax.98.1391454398675; Mon, 03 Feb 2014 11:06:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.234.193 with HTTP; Mon, 3 Feb 2014 11:06:18 -0800 (PST) In-Reply-To: <8FA52BBD-9A61-4795-9BA3-AB8B0A63EB98@fugue.com> References: <52EA3032.3050703@gmail.com> <52EA3361.1010501@gmail.com> <2EB6289E-C7FD-481F-99F9-E35730245943@employees.org> <52EA442D.3020707@gmail.com> <52EA47AA.90302@gmail.com> <1FE00515-A7AD-4C48-A7F2-63BA8696D818@darou.fr> <52EA4BB1.9010607@gmail.com> <2922CC94-540D-4215-899B-4722BD1C5EBC@employees.org> <52EF90BD.4070701@gmail.com> <18C8BE29C547CC4DBBCF3C4F0B8EC1780608ED@wds-exc1.okna.nominet.org.uk> <8B52F0C3-EB5A-48D1-9596-52302F6A4A3C@darou.fr> <8FA52BBD-9A61-4795-9BA3-AB8B0A63EB98@fugue.com> From: Lorenzo Colitti Date: Mon, 3 Feb 2014 11:06:18 -0800 Message-ID: To: Ted Lemon Content-Type: multipart/alternative; boundary=089e0153695c2796d704f18539e4 Cc: Ray Bellis , Alexandru Petrescu , Pierre Pfister , "homenet@ietf.org Group" , Ole Troan Subject: Re: [homenet] DHCP PD X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 19:06:41 -0000 --089e0153695c2796d704f18539e4 Content-Type: text/plain; charset=UTF-8 On Mon, Feb 3, 2014 at 6:51 AM, Ted Lemon wrote: > It may be that we weren't clear enough on this point, but that was > definitely an anticipated use case. > Perhaps, but if implementations don't actually do this (and I don't think they do), then it doesn't really matter what the intent was. --089e0153695c2796d704f18539e4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Feb 3, 2014 at 6:51 AM, Ted Lemon <mellon@fugue.com> wrot= e:
It may be that we wer= en't clear enough on this point, but that was definitely an anticipated= use case.

Perhaps, but if imp= lementations don't actually do this (and I don't think they do), th= en it doesn't really matter what the intent was.
--089e0153695c2796d704f18539e4-- From mellon@fugue.com Mon Feb 3 11:51:59 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 932C91A01DA for ; Mon, 3 Feb 2014 11:51:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lfx3Xu0FRvHB for ; Mon, 3 Feb 2014 11:51:57 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id A0ACF1A015A for ; Mon, 3 Feb 2014 11:51:57 -0800 (PST) Received: from [IPv6:2001:470:88a3::d083:d4fd:42be:3446] (unknown [IPv6:2001:470:88a3:0:d083:d4fd:42be:3446]) by toccata.fugue.com (Postfix) with ESMTPSA id C6A472381707; Mon, 3 Feb 2014 14:51:54 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ted Lemon In-Reply-To: Date: Mon, 3 Feb 2014 14:51:52 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <29DCB6B2-B428-4B45-8796-ACB09E40376A@fugue.com> References: <52EA3032.3050703@gmail.com> <52EA3361.1010501@gmail.com> <2EB6289E-C7FD-481F-99F9-E35730245943@employees.org> <52EA442D.3020707@gmail.com> <52EA47AA.90302@gmail.com> <1FE00515-A7AD-4C48-A7F2-63BA8696D818@darou.fr> <52EA4BB1.9010607@gmail.com> <2922CC94-540D-4215-899B-4722BD1C5EBC@employees.org> <52EF90BD.4070701@gmail.com> <18C8BE29C547CC4DBBCF3C4F0B8EC1780608ED@wds-exc1.okna.nominet.org.uk> <8B52F0C3-EB5A-48D1-9596-52302F6A4A3C@darou.fr> <8FA52BBD-9A61-4795-9BA3-AB8B0A63EB98@fugue.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1827) Cc: Ray Bellis , Alexandru Petrescu , Pierre Pfister , "homenet@ietf.org Group" , Ole Troan Subject: Re: [homenet] DHCP PD X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 19:51:59 -0000 On Feb 3, 2014, at 2:06 PM, Lorenzo Colitti wrote: > Perhaps, but if implementations don't actually do this (and I don't = think they do), then it doesn't really matter what the intent was. There are no homenet router implementations. From brian.e.carpenter@gmail.com Mon Feb 3 13:32:50 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CFD41A0248 for ; Mon, 3 Feb 2014 13:32:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7qN_Gt7x2X3 for ; Mon, 3 Feb 2014 13:32:48 -0800 (PST) Received: from mail-pb0-x232.google.com (mail-pb0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id C95911A0251 for ; Mon, 3 Feb 2014 13:32:47 -0800 (PST) Received: by mail-pb0-f50.google.com with SMTP id rq2so7579595pbb.37 for ; Mon, 03 Feb 2014 13:32:47 -0800 (PST) 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=OuWNKZ8vJ0IAiFmGBUs2SEWnrbbHJXjsz6sZkrkpDZc=; b=Q4XLG6ISWBlERvTqlZJnQKfp3G92Fpj33yPTHUf2KW/JFMidLFaRb1ZcnY8M2Al629 McTjoJirwZram10DGymj35SWZUMcFSdmXOwPw9MXWKQ3DjVwHbo32ILwGKoKzQe5ktZE +MRyZV3VhSjmqKICwEhLKeeuX9IkbFGQ5z+WlQktHUhuRSNMWwQf3p2R/jiZe23aaGAG EffNWy0GenZbzyDtgh31FlKSq7c+sFdd/3mrOt8r6vcMA0Rhcb+4dIAGjKlrr7OOxjxE lXDCR4KS/35bZppgSq+Qe6RmosxsBYZI9QDKPJKhWKzFM3yyFVMKCrWA/rQmk+Jwo6VI 32tQ== X-Received: by 10.68.171.4 with SMTP id aq4mr5709340pbc.150.1391463156238; Mon, 03 Feb 2014 13:32:36 -0800 (PST) Received: from [130.216.38.108] (sc-cs-567-laptop.cs.auckland.ac.nz. [130.216.38.108]) by mx.google.com with ESMTPSA id bc4sm59256300pbb.2.2014.02.03.13.32.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Feb 2014 13:32:35 -0800 (PST) Message-ID: <52F00AF2.70004@gmail.com> Date: Tue, 04 Feb 2014 10:32:34 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Juliusz Chroboczek References: <87iosy2tf4.wl%jch@pps.univ-paris-diderot.fr> <52EDBEDA.1020208@gmail.com> <871tzlmgu3.wl%jch@pps.univ-paris-diderot.fr> In-Reply-To: <871tzlmgu3.wl%jch@pps.univ-paris-diderot.fr> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Homenet protocol decisions X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 21:32:50 -0000 Juliusz, On 03/02/2014 08:53, Juliusz Chroboczek wrote: >> I happen to have one in mind. It's discussed for the case of >> carrier networks in >> http://tools.ietf.org/html/draft-jiang-config-negotiation-ps-02 > > I've now read this draft. Section 2.4 says things that I never even > considered, and I need to think it over. (In particular, functionality > such as what you describe there would be marvelous for monitoring tools.) > > There's only one point that I disagree with. In Section 4 you say: > > Multi-party negotiations are too complicated to be modeled and > there may be too many dependencies among the parties to converge > efficiently. > > If I read you right, you're disallowing the familiar claim/defend > scheme, where a node claims an address over multicast, and waits for > other nodes to disagree. (The best-known case is probably that of > DHCPv4, where implementations commonly make an ARP query before > assigning an address, but there's no reason why this shouldn't be an > intrinsic part of the configuration protocol.) I don't think we intended to exclude that, but there may well be scenarios where suitably scoped multicast isn't available. We were concerned about guaranteed convergence in a multi-party scenario, which seems tractable with (reasonably reliable) multicast. Anyway, this aspect needs more thought, thanks! Brian > > -- Juliusz > . > From brian.e.carpenter@gmail.com Mon Feb 3 13:36:46 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF2D91A0210 for ; Mon, 3 Feb 2014 13:36:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qcs38A-i8lMR for ; Mon, 3 Feb 2014 13:36:45 -0800 (PST) Received: from mail-pb0-x232.google.com (mail-pb0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 83A2C1A01EE for ; Mon, 3 Feb 2014 13:36:45 -0800 (PST) Received: by mail-pb0-f50.google.com with SMTP id rq2so7583479pbb.37 for ; Mon, 03 Feb 2014 13:36:45 -0800 (PST) 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=uBssoMJoHCREzXZ+E0KF2lAu6svCnW7ANCO4nf78K1w=; b=XMMektx4czHM+EkOJNu6Mgmnf4cOBr1/JKT6Z7x1oSJOk3o3HJuFFZpH81beoAflDZ 3YKrzgNpif/vu95/LeA+41QeSKWL9szHJzXmcO3UEOcIq83YzLa0te9nBsa7gM763r7I 1paLWRWwTFCcKnC9koJ+jj76hpgC55vt3aH1frVJqOdoDCFwPl3bTvrzG3IZr6E4hY1i Y7IWQdJwBRAkjM4KamCtmj3bvSY5Ec6VCjRX7eBcD2+6YAHaXlzX0IvKxyP3g8OwrF5j Zkp9N20i5aNAKZ8/mTZugsFHf3lnkUCYuAUcrhh80bpO8scZHX9W+iOhf9ZLWFyRwfVJ Mncg== X-Received: by 10.66.233.71 with SMTP id tu7mr39720020pac.22.1391463405518; Mon, 03 Feb 2014 13:36:45 -0800 (PST) Received: from [130.216.38.108] (sc-cs-567-laptop.cs.auckland.ac.nz. [130.216.38.108]) by mx.google.com with ESMTPSA id sq7sm59261371pbc.19.2014.02.03.13.36.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Feb 2014 13:36:44 -0800 (PST) Message-ID: <52F00BED.3010403@gmail.com> Date: Tue, 04 Feb 2014 10:36:45 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ted Lemon References: <87iosy2tf4.wl%jch@pps.univ-paris-diderot.fr> <52EDBEDA.1020208@gmail.com> <32165.1391437144@sandelman.ca> <9109.1391439610@sandelman.ca> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Michael Richardson , "homenet@ietf.org Group" Subject: Re: [homenet] Homenet protocol decisions X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 21:36:47 -0000 On 04/02/2014 04:29, Ted Lemon wrote: > On Feb 3, 2014, at 10:00 AM, Michael Richardson wrote: >> I am also skeptical that there are significant configuration things in the >> homenet which *do not* ultimately need to share fate with connectivity. > > ULA seems like an obvious example. If the network gets split, ULA connectivity breaks too. Brian From markus.stenberg@iki.fi Tue Feb 4 03:41:00 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0BB41A03F3 for ; Tue, 4 Feb 2014 03:41:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVhkMxGHx7Gu for ; Tue, 4 Feb 2014 03:40:58 -0800 (PST) Received: from jenni2.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 45D951A039E for ; Tue, 4 Feb 2014 03:40:58 -0800 (PST) Received: from kosame.lan (80.220.67.193) by jenni2.inet.fi (8.5.140.03) (authenticated as stenma-47) id 52775C99079AA799; Tue, 4 Feb 2014 13:40:50 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Markus Stenberg In-Reply-To: <29DCB6B2-B428-4B45-8796-ACB09E40376A@fugue.com> Date: Tue, 4 Feb 2014 13:40:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52EA3032.3050703@gmail.com> <52EA3361.1010501@gmail.com> <2EB6289E-C7FD-481F-99F9-E35730245943@employees.org> <52EA442D.3020707@gmail.com> <52EA47AA.90302@gmail.com> <1FE00515-A7AD-4C48-A7F2-63BA8696D818@darou.fr> <52EA4BB1.9010607@gmail.com> <2922CC94-540D-4215-899B-4722BD1C5EBC@employees.org> <52EF90BD.4070701@gmail.com> <18C8BE29C547CC4DBBCF3C4F0B8EC1780608ED@wds-exc1.okna.nominet.org.uk> <8B52F0C3-EB5A-48D1-9596-52302F6A4A3C@darou.fr> <8FA52BBD-9A61-4795-9BA3-AB8B0A63EB98@fugue.com> <29DCB6B2-B428-4B45-8796-ACB09E40376A@fugue.com> To: Ted Lemon X-Mailer: Apple Mail (2.1827) Cc: Alexandru Petrescu , Markus Stenberg , Ray Bellis , Ole Troan , Pierre Pfister , "homenet@ietf.org Group" , Lorenzo Colitti Subject: Re: [homenet] DHCP PD X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 11:41:00 -0000 On 3.2.2014, at 21.51, Ted Lemon wrote: > On Feb 3, 2014, at 2:06 PM, Lorenzo Colitti = wrote: >> Perhaps, but if implementations don't actually do this (and I don't = think they do), then it doesn't really matter what the intent was. > There are no homenet router implementations. Given N*10^8+ (conservative estimate, N some single digit probably) = potential homenet hosts already out there and 0 homenet routers, = designing with the assumption that =91yeah, hosts can change=92 doesn=92t = sound too reasonable to me. Then again, what=92s wrong with fighting windmills? Cheers, -Markus From mellon@fugue.com Tue Feb 4 05:46:17 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90FDB1A044F for ; Tue, 4 Feb 2014 05:46:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CD-Ao6LNmOgF for ; Tue, 4 Feb 2014 05:46:12 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 8D6BD1A0430 for ; Tue, 4 Feb 2014 05:46:12 -0800 (PST) Received: from [IPv6:2001:470:88a3::5592:c051:de65:ce6e] (unknown [IPv6:2001:470:88a3:0:5592:c051:de65:ce6e]) by toccata.fugue.com (Postfix) with ESMTPSA id A988B23814DB; Tue, 4 Feb 2014 08:46:09 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ted Lemon In-Reply-To: Date: Tue, 4 Feb 2014 08:46:08 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52EA3032.3050703@gmail.com> <52EA3361.1010501@gmail.com> <2EB6289E-C7FD-481F-99F9-E35730245943@employees.org> <52EA442D.3020707@gmail.com> <52EA47AA.90302@gmail.com> <1FE00515-A7AD-4C48-A7F2-63BA8696D818@darou.fr> <52EA4BB1.9010607@gmail.com> <2922CC94-540D-4215-899B-4722BD1C5EBC@employees.org> <52EF90BD.4070701@gmail.com> <18C8BE29C547CC4DBBCF3C4F0B8EC1780608ED@wds-exc1.okna.nominet.org.uk> <8B52F0C3-EB5A-48D1-9596-52302F6A4A3C@darou.fr> <8FA52BBD-9A61-4795-9BA3-AB8B0A63EB98@fugue.com> <29DCB6B2-B428-4B45-8796-ACB09E40376A@fugue.com> To: Markus Stenberg X-Mailer: Apple Mail (2.1827) Cc: Alexandru Petrescu , Ray Bellis , Ole Troan , Pierre Pfister , "homenet@ietf.org Group" , Lorenzo Colitti Subject: Re: [homenet] DHCP PD X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 13:46:17 -0000 On Feb 4, 2014, at 6:40 AM, Markus Stenberg = wrote: > Given N*10^8+ (conservative estimate, N some single digit probably) = potential homenet hosts already out there and 0 homenet routers, = designing with the assumption that =91yeah, hosts can change=92 doesn=92t = sound too reasonable to me. >=20 > Then again, what=92s wrong with fighting windmills? We're talking about prefix delegation. Prefix delegation runs on = routers, not hosts. From otroan@employees.org Tue Feb 4 06:09:25 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49FC61A00DF for ; Tue, 4 Feb 2014 06:09:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y1czhNTDN-pK for ; Tue, 4 Feb 2014 06:09:24 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id F23F81A00DB for ; Tue, 4 Feb 2014 06:09:23 -0800 (PST) X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkcFAMPz8FKQ/khR/2dsb2JhbABZgwy/JoELFnSCJQEBBAF5EAsOOFcGiBAIzicXjnUHgySBFAEDkD+aDYMuOw X-IronPort-AV: E=Sophos;i="4.95,779,1384300800"; d="asc'?scan'208";a="3977037" Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-2.cisco.com with ESMTP; 04 Feb 2014 14:09:23 +0000 Received: from dhcp-10-61-106-13.cisco.com (dhcp-10-61-106-13.cisco.com [10.61.106.13]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s14E9LCT029175 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 4 Feb 2014 14:09:22 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_8053413C-A422-402B-AE6A-B578280F483C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ole Troan In-Reply-To: Date: Tue, 4 Feb 2014 15:09:21 +0100 Message-Id: <8FB38433-5358-4172-968C-76564A875520@employees.org> References: <52EA3032.3050703@gmail.com> <52EA3361.1010501@gmail.com> <2EB6289E-C7FD-481F-99F9-E35730245943@employees.org> <52EA442D.3020707@gmail.com> <52EA47AA.90302@gmail.com> <1FE00515-A7AD-4C48-A7F2-63BA8696D818@darou.fr> <52EA4BB1.9010607@gmail.com> <2922CC94-540D-4215-899B-4722BD1C5EBC@employees.org> <52EF90BD.4070701@gmail.com> <18C8BE29C547CC4DBBCF3C4F0B8EC1780608ED@wds-exc1.okna.nominet.org.uk> <8B52F0C3-EB5A-48D1-9596-52302F6A4A3C@darou.fr> <8FA52BBD-9A61-4795-9BA3-AB8B0A63EB98@fugue.com> <29DCB6B2-B428-4B45-8796-ACB09E40376A@fugue.com> To: Ted Lemon X-Mailer: Apple Mail (2.1827) Cc: Alexandru Petrescu , Markus Stenberg , Ray Bellis , Pierre Pfister , "homenet@ietf.org Group" , Lorenzo Colitti Subject: Re: [homenet] DHCP PD X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 14:09:25 -0000 --Apple-Mail=_8053413C-A422-402B-AE6A-B578280F483C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 >> Given N*10^8+ (conservative estimate, N some single digit probably) = potential homenet hosts already out there and 0 homenet routers, = designing with the assumption that =91yeah, hosts can change=92 doesn=92t = sound too reasonable to me. >>=20 >> Then again, what=92s wrong with fighting windmills? >=20 > We're talking about prefix delegation. Prefix delegation runs on = routers, not hosts. actually, we're talking about prefix assignment. which may be splitting = hairs, but isn't quite the same as prefix delegation. cheers, Ole --Apple-Mail=_8053413C-A422-402B-AE6A-B578280F483C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJS8PSRAAoJEFuJXizso86gsMkH/jKAmbqcUZNBM+R1oDzm6gpj 4MrikG0QC+VUHtF4/ihRYqGiYzabUG+M672FtWU4gSHFId7u8Gx57J8nN2g+nKX4 /2qJmPcpQPhBf0vG99j+Rh+WRO4TdPiYTNvBJ1lZzknXgZXPHBDBChfR+VZSh/Ad fWiFvQRM1u/1Li7QsvC3YjOQyIib0eICgP6/kgZRtGROHdpvOEry2M3NIsaPJ8+d LtoWamQDUl5S7IjXrqcTtNxqQejLi3VFKKCiP8Oync8pBjXboXjRBGX2hcIdyCDk w4SyL57PeJnGDsqQuvOGI4L6nIfKAMeL8MXo5UzvfyfZTrXoyO6JEfSALrj6wAI= =m+cK -----END PGP SIGNATURE----- --Apple-Mail=_8053413C-A422-402B-AE6A-B578280F483C-- From mellon@fugue.com Tue Feb 4 06:16:43 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D3A81A00EC for ; Tue, 4 Feb 2014 06:16:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q28fSLgEDb96 for ; Tue, 4 Feb 2014 06:16:42 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 7C3171A011D for ; Tue, 4 Feb 2014 06:16:41 -0800 (PST) Received: from [IPv6:2001:470:88a3::5592:c051:de65:ce6e] (unknown [IPv6:2001:470:88a3:0:5592:c051:de65:ce6e]) by toccata.fugue.com (Postfix) with ESMTPSA id AD20023814DB; Tue, 4 Feb 2014 09:16:38 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ted Lemon In-Reply-To: <8FB38433-5358-4172-968C-76564A875520@employees.org> Date: Tue, 4 Feb 2014 09:16:37 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52EA3032.3050703@gmail.com> <52EA3361.1010501@gmail.com> <2EB6289E-C7FD-481F-99F9-E35730245943@employees.org> <52EA442D.3020707@gmail.com> <52EA47AA.90302@gmail.com> <1FE00515-A7AD-4C48-A7F2-63BA8696D818@darou.fr> <52EA4BB1.9010607@gmail.com> <2922CC94-540D-4215-899B-4722BD1C5EBC@employees.org> <52EF90BD.4070701@gmail.com> <18C8BE29C547CC4DBBCF3C4F0B8EC1780608ED@wds-exc1.okna.nominet.org.uk> <8B52F0C3-EB5A-48D1-9596-52302F6A4A3C@darou.fr> <8FA52BBD-9A61-4795-9BA3-AB8B0A63EB98@fugue.com> <29DCB6B2-B428-4B45-8796-ACB09E40376A@fugue.com> <8FB38433-5358-4172-968C-76564A875520@employees.org> To: Ole Troan X-Mailer: Apple Mail (2.1827) Cc: Alexandru Petrescu , Markus Stenberg , Ray Bellis , Pierre Pfister , "homenet@ietf.org Group" , Lorenzo Colitti Subject: Re: [homenet] DHCP PD X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 14:16:43 -0000 On Feb 4, 2014, at 9:09 AM, Ole Troan wrote: > actually, we're talking about prefix assignment. which may be = splitting hairs, but isn't quite the same as prefix delegation. Splain? You mean we're talking about the general problem, rather than = the DHCP-PD solution? If so, that's fine, but the specific comment = that Markus made was about DHCP PD, and that's what I was responding to. = I am not specifically advocating the use of DHCP PD to solve this = problem, but I do want to see it evaluated realistically, and not on the = basis of a misunderstanding of what it does and how it's used. From mcr@sandelman.ca Tue Feb 4 06:58:48 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2051D1A00EC for ; Tue, 4 Feb 2014 06:58:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.009 X-Spam-Level: * X-Spam-Status: No, score=1.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Xl_RnfXsWQG for ; Tue, 4 Feb 2014 06:58:46 -0800 (PST) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 5B2FE1A00E4 for ; Tue, 4 Feb 2014 06:58:46 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id C7C102002F for ; Tue, 4 Feb 2014 11:15:37 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id B4778647C9; Tue, 4 Feb 2014 09:58:41 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 69503647C8 for ; Tue, 4 Feb 2014 09:58:41 -0500 (EST) From: Michael Richardson To: "homenet@ietf.org Group" In-Reply-To: References: <52EA3032.3050703@gmail.com> <52EA3361.1010501@gmail.com> <2EB6289E-C7FD-481F-99F9-E35730245943@employees.org> <52EA442D.3020707@gmail.com> <52EA47AA.90302@gmail.com> <1FE00515-A7AD-4C48-A7F2-63BA8696D818@darou.fr> <52EA4BB1.9010607@gmail.com> <2922CC94-540D-4215-899B-4722BD1C5EBC@employees.org> <52EF90BD.4070701@gmail.com> <18C8BE29C547CC4DBBCF3C4F0B8EC1780608ED@wds-exc1.okna.nominet.org.uk> <8B52F0C3-EB5A-48D1-9596-52302F6A4A3C@darou.fr> <8FA52BBD-9A61-4795-9BA3-AB8B0A63EB98@fugue.com> <29DCB6B2-B428-4B45-8796-ACB09E40376A@fugue.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Subject: Re: [homenet] DHCP PD X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 14:58:48 -0000 To quote from the charter: Prefix configuration, routing, and security related work shall not cause any changes that are not backwards compatible to existing IPv6 hosts. There may be host visible changes in the work on naming and discovery protocols, however. "backwards compatible" doesn't mean that we can't write down things where a smarter newer host can get better service. It means that existing hosts must get some kind of service, regardless. From teco@inf-net.nl Tue Feb 4 07:57:01 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83A9F1A011C for ; Tue, 4 Feb 2014 07:57:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nTey63_POKJV for ; Tue, 4 Feb 2014 07:56:59 -0800 (PST) Received: from mail-we0-f179.google.com (mail-we0-f179.google.com [74.125.82.179]) by ietfa.amsl.com (Postfix) with ESMTP id 749881A00E2 for ; Tue, 4 Feb 2014 07:56:58 -0800 (PST) Received: by mail-we0-f179.google.com with SMTP id q58so4247393wes.24 for ; Tue, 04 Feb 2014 07:56:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=HRQyYoExQGghK2SUD4KixQU3qDAx26Y907ZsqethFoc=; b=HWFne7L1+9Hh/PZ7kgVhAxDXsdM5nH5UPOCeEVY7myBhJvheIZPHInUL7OZrP/Mt6A BU8EzT3l/INngxt3raZqOtPlxhocrFzcba0Y6utAszKzX3QA6FBO+jw6WhcVFgiPB5Q5 woPWZEAlNx5wl+tw4jYDmnPfNDpUCeRMIYjE0uuxZxKZrnvFp5AJiYQ6FUh1hUBtRA1m DctAVwTEwpKlAk2RqM/iPBZgx/Phnldgp9OgqZejVYhjYusbQ9CLhlfwxiZF41Z1pVO/ Pf/DWQEYSAAyLvVE8moxXvgKcykunsMVUNWgxJ3+D0JmE2alwItXhhg7/bVzuHGknglh aksQ== X-Gm-Message-State: ALoCoQlYirb3n/tor775T4zWOW5umsYuA3PTJa/IIBOKwUF7CzAaYrlGYfx70guimGLdahXDtkHD X-Received: by 10.180.185.197 with SMTP id fe5mr13181929wic.56.1391529417956; Tue, 04 Feb 2014 07:56:57 -0800 (PST) Received: from [172.20.10.3] ([84.241.210.97]) by mx.google.com with ESMTPSA id q2sm53654309wjq.0.2014.02.04.07.56.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Feb 2014 07:56:56 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Teco Boot In-Reply-To: Date: Tue, 4 Feb 2014 16:35:57 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5B7762A1-F133-4274-A241-7CF02BD8F8A9@inf-net.nl> <86D0DCEC-C01D-49CA-AA54-93666180B37C@inf-net.nl> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1827) Cc: Ole Troan , "homenet@ietf.org Group" , Mikael Abrahamsson Subject: Re: [homenet] Homenet protocol decisions X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 15:57:01 -0000 Op 2 feb. 2014, om 06:41 heeft Lorenzo Colitti het = volgende geschreven: > On Sat, Feb 1, 2014 at 2:45 AM, Teco Boot wrote: > >> First we have to verify if this can happen. My favorite is using = DHCP-PD with server on CPE (edge) box (and elected box for ULA). This = box should circumvent your scenario. > >> > > Er, *what*? You are aware that if you have a partition, one of the = two partitions will not be able to reach the DHCP server? >=20 > Does it matter? Prefixes for unreachable DHCP servers should be = deprecated. Leases wil expire. A mobility tool is needed for connection = survival (MPTCP, whatever). >=20 > You can't reliably deprecate information in DHCP. Even if the client = supports the reconfigure option, deprecating something in DHCP requires = that the server that has the original nonce still be up and around. >=20 > This is why DHCP is not a good protocol to use in a distributed, = unreliable network like a homenet. Enterprise networks transform to distributed, unreliable networks = (wireless access, BYOD with cellular access, sensors). At least some of = them. Replace DHCP? I do not suggest full end-to-end DHCP connections from hosts to single = DHCP server. I suggest structuring the Homenet somewhat, with clearly = defined services for different tasks. I don=92t see a problem using DHCP = server on CPE box managing info for ISP connected via that box. And a = DHCP server on leaf routers managing info provided to attached clients. = Why not using DHCP between? Your reachability dependency argument is solved easily, let=92s mandate = the Homenet DHCP server advertises its DHCP server address (/128) in the = routing protocol. Homenet routers watch these entries. Why not let Homenet routers MUST implement DHCP reconfigure extension, = at least for their DHCP Client function? Of course I suggest DHCP as just one of the Homenet components. Teco =20= From teco@inf-net.nl Tue Feb 4 07:57:02 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A03041A00E2 for ; Tue, 4 Feb 2014 07:57:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJ2EVArY6sS3 for ; Tue, 4 Feb 2014 07:57:01 -0800 (PST) Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) by ietfa.amsl.com (Postfix) with ESMTP id 4D68E1A011A for ; Tue, 4 Feb 2014 07:57:01 -0800 (PST) Received: by mail-wg0-f51.google.com with SMTP id z12so12802326wgg.18 for ; Tue, 04 Feb 2014 07:57:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=og1s9RsHMReQP5Z2phYepE4eAZQzUb5ojRdtwaiAjTo=; b=dAy1OnfvIyT0S9oFswdqPgMPo4bjmXda8K/GauSRxUr6hlsybR6edGnLyd8l7Aa7JD WKBQZGrO1hx2+u8s257ySJGoNIQBdtH/F1KY5h7t+oVR5V20vdaDSAJPamGjYD4u89WC OX/UP0mVU4HKYWXWRA/zZy3IFTT7s+MuVttp2fIr6vugLRQjTn/NtgktFlp8+sSGgMY3 Y2u/zOBgSQ7UReTbJCS8quyu/Ks1YEAImoJvBzRy32EHWwtkkbt8hV+asbYuxsxaZh1W OdMxL0eLR5n7s/RHlSnGdeiZ5CKZGG3GWtaXzZlX/vad287wUkF4CIuBUBpL5E6KLHSm ghTA== X-Gm-Message-State: ALoCoQktdWYKUIjwE7eYTHLppE3QwK/c2BJNpktiMlfRGhKzJE1pSTG8L1zisMnesFxbNSJQCORW X-Received: by 10.194.240.7 with SMTP id vw7mr936868wjc.75.1391529420479; Tue, 04 Feb 2014 07:57:00 -0800 (PST) Received: from [172.20.10.3] ([84.241.210.97]) by mx.google.com with ESMTPSA id q2sm53654309wjq.0.2014.02.04.07.56.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Feb 2014 07:56:59 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Teco Boot In-Reply-To: <18C8BE29C547CC4DBBCF3C4F0B8EC1780608ED@wds-exc1.okna.nominet.org.uk> Date: Tue, 4 Feb 2014 16:51:24 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8757F497-E621-40D9-95AC-C52066A6AFD5@inf-net.nl> References: <52EA3032.3050703@gmail.com> <52EA3361.1010501@gmail.com> <2EB6289E-C7FD-481F-99F9-E35730245943@employees.org> <52EA442D.3020707@gmail.com> <52EA47AA.90302@gmail.com> <1FE00515-A7AD-4C48-A7F2-63BA8696D818@darou.fr> <52EA4BB1.9010607@gmail.com> <2922CC94-540D-4215-899B-4722BD1C5EBC@employees.org> <52EF90BD.4070701@gmail.com> <18C8BE29C547CC4DBBCF3C4F0B8EC1780608ED@wds-exc1.okna.nominet.org.uk> To: Ray Bellis X-Mailer: Apple Mail (2.1827) Cc: Alexandru Petrescu , "homenet@ietf.org Group" , Pierre Pfister , Ole Troan Subject: Re: [homenet] DHCP PD X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 15:57:02 -0000 Op 3 feb. 2014, om 15:11 heeft Ray Bellis = het volgende geschreven: >=20 > On 3 Feb 2014, at 12:51, Alexandru Petrescu = wrote: >=20 >> In this setting the Router3 could run two DHCPRelay processes, and = Router1 and 2 would be Servers. >>=20 >> This would allow Host to obtain an address from each (=3D=3Dmulti-homed= ). >=20 > It could, but assume that Router3 doesn't yet know anything about the = upstream topology. We have to come up with border router discovery. Are you interested in = details on transient state right now? Teco From jch@pps.univ-paris-diderot.fr Tue Feb 4 08:35:19 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C66691A01AE for ; Tue, 4 Feb 2014 08:35:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bTuuR5uFq2OP for ; Tue, 4 Feb 2014 08:35:18 -0800 (PST) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) by ietfa.amsl.com (Postfix) with ESMTP id AA1DD1A011C for ; Tue, 4 Feb 2014 08:35:17 -0800 (PST) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/46573) with ESMTP id s14GZGpa020985 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 4 Feb 2014 17:35:16 +0100 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/46573) with ESMTP id s14GZG9G019100; Tue, 4 Feb 2014 17:35:16 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 2236F6F437; Tue, 4 Feb 2014 17:35:16 +0100 (CET) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id S6GDh1HVCtdn; Tue, 4 Feb 2014 17:35:15 +0100 (CET) Received: from lanthane.pps.univ-paris-diderot.fr (unknown [172.23.36.54]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 0910A6F3D6; Tue, 4 Feb 2014 17:35:14 +0100 (CET) Received: from localhost ([::1] helo=lanthane.pps.univ-paris-diderot.fr) by lanthane.pps.univ-paris-diderot.fr with esmtp (Exim 4.82) (envelope-from ) id 1WAixu-0005Js-NL; Tue, 04 Feb 2014 17:35:14 +0100 Date: Tue, 04 Feb 2014 17:35:14 +0100 Message-ID: <7izjm6q1j1.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Alexandru Petrescu In-Reply-To: <52EF5BAD.3000907@gmail.com> References: <87bnyq2rhb.wl%jch@pps.univ-paris-diderot.fr> <52EF5BAD.3000907@gmail.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Tue, 04 Feb 2014 17:35:16 +0100 (CET) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Tue, 04 Feb 2014 17:35:16 +0100 (CET) X-Miltered: at korolev with ID 52F116C4.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 52F116C4.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 52F116C4.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 52F116C4.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 52F116C4.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 52F116C4.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Cc: homenet@ietf.org Subject: Re: [homenet] Homenet protocol decisions X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 16:35:20 -0000 > First, I would try to understand what is meant by partitioned network. http://www.ietf.org/rfc/ien/ien110.txt http://www.ietf.org/rfc/ien/ien146.txt -- Juliusz (who sometimes enjoys reading old papers) From alexandru.petrescu@gmail.com Tue Feb 4 09:02:40 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1E9E1A013B for ; Tue, 4 Feb 2014 09:02:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NRrAGTTGlmEN for ; Tue, 4 Feb 2014 09:02:38 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 70DDE1A011C for ; Tue, 4 Feb 2014 09:02:38 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s14H2bG8018800; Tue, 4 Feb 2014 18:02:37 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A4746202CE9; Tue, 4 Feb 2014 18:02:56 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 8EF85202C68; Tue, 4 Feb 2014 18:02:56 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s14H2aXY016281; Tue, 4 Feb 2014 18:02:37 +0100 Message-ID: <52F11D2D.4030608@gmail.com> Date: Tue, 04 Feb 2014 18:02:37 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Juliusz Chroboczek References: <87bnyq2rhb.wl%jch@pps.univ-paris-diderot.fr> <52EF5BAD.3000907@gmail.com> <7izjm6q1j1.wl%jch@pps.univ-paris-diderot.fr> In-Reply-To: <7izjm6q1j1.wl%jch@pps.univ-paris-diderot.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: homenet@ietf.org Subject: Re: [homenet] Homenet protocol decisions X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 17:02:40 -0000 Le 04/02/2014 17:35, Juliusz Chroboczek a écrit : >> First, I would try to understand what is meant by partitioned >> network. > > http://www.ietf.org/rfc/ien/ien110.txt > http://www.ietf.org/rfc/ien/ien146.txt > > -- Juliusz (who sometimes enjoys reading old papers) Thanks. It is indeed enjoying to see how far this term comes from. Ok, a homenet may become partitioned if grandma's IPv6 Access Point only links a smartphone to a scale, but not to the Internet. To avoid the homenet partitioning, one would need a means for the Access Point to connect to the Internet, get prefixes, advertise prefixes, self-configure prefixes, deliver addresses, establish routes, forward end-to-end traffic (w/o touching other fields than the Hop Limit) seamlessly, with zero pre-configuration. Alex From markus.stenberg@iki.fi Tue Feb 4 09:10:50 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54A3A1A0120 for ; Tue, 4 Feb 2014 09:10:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pvJ63TlgstRW for ; Tue, 4 Feb 2014 09:10:48 -0800 (PST) Received: from jenni2.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id CA1C51A011D for ; Tue, 4 Feb 2014 09:10:47 -0800 (PST) Received: from kosame.lan (80.220.67.193) by jenni2.inet.fi (8.5.140.03) (authenticated as stenma-47) id 52775C9907A1B592; Tue, 4 Feb 2014 19:10:34 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Markus Stenberg In-Reply-To: Date: Tue, 4 Feb 2014 19:10:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52EA3032.3050703@gmail.com> <52EA3361.1010501@gmail.com> <2EB6289E-C7FD-481F-99F9-E35730245943@employees.org> <52EA442D.3020707@gmail.com> <52EA47AA.90302@gmail.com> <1FE00515-A7AD-4C48-A7F2-63BA8696D818@darou.fr> <52EA4BB1.9010607@gmail.com> <2922CC94-540D-4215-899B-4722BD1C5EBC@employees.org> <52EF90BD.4070701@gmail.com> <18C8BE29C547CC4DBBCF3C4F0B8EC1780608ED@wds-exc1.okna.nominet.org.uk> <8B52F0C3-EB5A-48D1-9596-52302F6A4A3C@darou.fr> <8FA52BBD-9A61-4795-9BA3-AB8B0A63EB98@fugue.com> <29DCB6B2-B428-4B45-8796-ACB09E40376A@fugue.com> To: Ted Lemon X-Mailer: Apple Mail (2.1827) Cc: Alexandru Petrescu , Markus Stenberg , Ray Bellis , Ole Troan , Pierre Pfister , "homenet@ietf.org Group" , Lorenzo Colitti Subject: Re: [homenet] DHCP PD X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 17:10:50 -0000 On 4.2.2014, at 15.46, Ted Lemon wrote: > On Feb 4, 2014, at 6:40 AM, Markus Stenberg = wrote: >> Given N*10^8+ (conservative estimate, N some single digit probably) = potential homenet hosts already out there and 0 homenet routers, = designing with the assumption that =91yeah, hosts can change=92 doesn=92t = sound too reasonable to me. >>=20 >> Then again, what=92s wrong with fighting windmills? > We're talking about prefix delegation. Prefix delegation runs on = routers, not hosts. Quoting you: This is not actually true. RFC 3315 was written with the clear = anticipation of the possibility that a DHCP client might talk to = multiple DHCP servers. It doesn=92t specifically require this = behavior, and it doesn't always make sense, but if you have two managed = prefixes on a wire, I would expect a DHCP client to try to configure = both of them, and if two DHCP servers each manage one of the prefixes, I = would expect the DHCP client to wind up getting configurations from two = servers. I thought you were asking for host changes to support multiple servers = (even if RFC says they should, and I=92m not sure it does, I have yet to = find one that does). Cheers, -Markus= From mellon@fugue.com Tue Feb 4 09:23:10 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04B561A00F9 for ; Tue, 4 Feb 2014 09:23:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pqRuArNfb3Pg for ; Tue, 4 Feb 2014 09:23:05 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 777761A011F for ; Tue, 4 Feb 2014 09:23:05 -0800 (PST) Received: from [IPv6:2001:470:88a3::5592:c051:de65:ce6e] (unknown [IPv6:2001:470:88a3:0:5592:c051:de65:ce6e]) by toccata.fugue.com (Postfix) with ESMTPSA id 5163C23807EC; Tue, 4 Feb 2014 12:23:02 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ted Lemon In-Reply-To: Date: Tue, 4 Feb 2014 12:23:01 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52EA3032.3050703@gmail.com> <52EA3361.1010501@gmail.com> <2EB6289E-C7FD-481F-99F9-E35730245943@employees.org> <52EA442D.3020707@gmail.com> <52EA47AA.90302@gmail.com> <1FE00515-A7AD-4C48-A7F2-63BA8696D818@darou.fr> <52EA4BB1.9010607@gmail.com> <2922CC94-540D-4215-899B-4722BD1C5EBC@employees.org> <52EF90BD.4070701@gmail.com> <18C8BE29C547CC4DBBCF3C4F0B8EC1780608ED@wds-exc1.okna.nominet.org.uk> <8B52F0C3-EB5A-48D1-9596-52302F6A4A3C@darou.fr> <8FA52BBD-9A61-4795-9BA3-AB8B0A63EB98@fugue.com> <29DCB6B2-B428-4B45-8796-ACB09E40376A@fugue.com> To: Markus Stenberg X-Mailer: Apple Mail (2.1827) Cc: Alexandru Petrescu , Ray Bellis , Ole Troan , Pierre Pfister , "homenet@ietf.org Group" , Lorenzo Colitti Subject: Re: [homenet] DHCP PD X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 17:23:10 -0000 On Feb 4, 2014, at 12:10 PM, Markus Stenberg = wrote: > I thought you were asking for host changes to support multiple servers = (even if RFC says they should, and I=92m not sure it does, I have yet to = find one that does). I think host changes to make this work will be crucial to having hosts = that can operate on multiple prefixes managed by different organizations = on the same wire, but I don't think that homenet clients need this, = because most likely they'll be doing SLAAC, and maybe getting some local = configuration parameters with stateless DHCP, which themselves would = have to be derived automatically by the homenet, either through internal = communication or from externally-received information. From mcr@sandelman.ca Tue Feb 4 15:13:59 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85F851A0162 for ; Tue, 4 Feb 2014 15:13:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.009 X-Spam-Level: * X-Spam-Status: No, score=1.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V_e3awIuw8di for ; Tue, 4 Feb 2014 15:13:57 -0800 (PST) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 63A521A0135 for ; Tue, 4 Feb 2014 15:13:57 -0800 (PST) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9E5722002F; Tue, 4 Feb 2014 19:30:52 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id AC10C647C9; Tue, 4 Feb 2014 18:13:55 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 9898A63B88; Tue, 4 Feb 2014 18:13:55 -0500 (EST) From: Michael Richardson To: Pierre Pfister In-Reply-To: <2BE96E0A-D9A7-492F-B07F-9C83767C6F0D@darou.fr> References: <52EA3032.3050703@gmail.com> <52EA3361.1010501@gmail.com> <2EB6289E-C7FD-481F-99F9-E35730245943@employees.org> <52EA442D.3020707@gmail.com> <52EA47AA.90302@gmail.com> <1FE00515-A7AD-4C48-A7F2-63BA8696D818@darou.fr> <52EA4BB1.9010607@gmail.com> <2922CC94-540D-4215-899B-4722BD1C5EBC@employees.org> <52EF90BD.4070701@gmail.com> <18C8BE29C547CC4DBBCF3C4F0B8EC1780608ED@wds-exc1.okna.nominet.org.uk> <8B52F0C3-EB5A-48D1-9596-52302F6A4A3C@darou.fr> <8FA52BBD-9A61-4795-9BA3-AB8B0A63EB98@fugue.com> <29DCB6B2-B428-4B45-8796-ACB09E40376A@fugue.com> <26945.1391525921@sandelman.ca> <2BE96E0A-D9A7-492F-B07F-9C83767C6F0D@darou.fr> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: "homenet@ietf.org Group" Subject: Re: [homenet] DHCP PD X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 23:13:59 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Pierre Pfister wrote: >> To quote from the charter: >>=20 >> Prefix configuration, routing, and security related work shall not >> cause any changes that are not backwards compatible to existing IPv6 >> hosts. There may be host visible changes in the work on naming and >> discovery protocols, however. >>=20 >> "backwards compatible" doesn't mean that we can't write down things >> where a smarter newer host can get better service. It means that >> existing hosts must get some kind of service, regardless. > In a multi-homing case, multiple ISP would provide multiple > prefixes. It is expected that, with colored prefixes, each prefixes > will be attached dedicated services. When there is a single ISP, > DHCP-PD can serve the prefixes correctly to the host. But in a There are a number of possibilities where "backwards compatible" might mean different things. Let's take your voice application example: > For instance, if a prefix is for general purpose, and another is for voice > applications, then hosts may only get addresses for voice application, and > would therefore not being able to access the internet.=20=20 So, prior to homenet, what happens? (If the answer is no v6, then stop.) If it that the phones get plugged into the voip router, and the computers get plugged into the internet router, and the two are not connected, then that is in fact still an option. If the routers are upgraded with homenet, and now interconnected then to remain backwards compatible I would expect: 1) the phones without required upgrades to remain plugged into the voice router. 2) hosts that can accept two prefixes and pick the right prefix can run the soft voice application. 3) hosts that can not accept two prefixes (really? that's in the spec for a long time), would have a problem. They weren't to spec. 4) hosts that can accept two prefixes would attempt to use the voice prefix for internet access, get a no-route-to-host, and happy eyeballs would do the right thing. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 =20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUvF0MYqHRg3pndX9AQIFswQAyrrm8MGwNAvDm0VDvlv2lNNaPbKl9Clt 4TqLXwSA8zsBn9lKI9rbcSfDSbDPQFZRw94hiTKfrfWxBj/ZdmUh9TEQ8VxLBF8I 7LdSrHrRSHpyTb8d+CNzY8vzSzjxjalECbkH9S3PS7Sg8hAqtuc7mcHO+aZZqWno usBe/iSDkLQ= =xAWA -----END PGP SIGNATURE----- --=-=-=-- From brian.e.carpenter@gmail.com Tue Feb 4 18:50:02 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CD3F1A0006 for ; Tue, 4 Feb 2014 18:50:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NjvUtna0_GAU for ; Tue, 4 Feb 2014 18:50:01 -0800 (PST) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id DF9C71A0004 for ; Tue, 4 Feb 2014 18:50:00 -0800 (PST) Received: by mail-pd0-f182.google.com with SMTP id v10so9094594pde.27 for ; Tue, 04 Feb 2014 18:50:00 -0800 (PST) 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=l0ZUnc78JdFeMRDWPVr6PDQH8edG3DRY1SeBk2Iw0mw=; b=fIyKCVqdxdMtnlRKfapmN6uuN/kJJQ0htMHoArpQKaQ4ltG5WuT/bXnfgSnIRSf1K4 v+6iz/0QnWnAzpKOgZwFBQe/frvVvhEh2Zg9c+HTtYLCAZXMklWlKef+JPL7E/p669VW jQlJk2bmqoHalkVThRJpaihEVDk+RaBmfkmrSM0y2f+SCUNY89+HNoKdvtV5mrLjOU6b 31QleKksxYjDgTbNW9pFCOF4RsFt3OiCPrzJu7qBXD6ickEvOZMLVSjWfwtBH5u50uVZ GQCHHb5vKVGHuayN9atFmqIRg67N/RBGcIlyPTuLzQovXcnazLymxdLzVdgSwE/aEXDB Lx2Q== X-Received: by 10.66.146.229 with SMTP id tf5mr48281668pab.50.1391568600476; Tue, 04 Feb 2014 18:50:00 -0800 (PST) Received: from [192.168.178.23] (98.198.69.111.dynamic.snap.net.nz. [111.69.198.98]) by mx.google.com with ESMTPSA id rb6sm35251345pbb.41.2014.02.04.18.49.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Feb 2014 18:49:59 -0800 (PST) Message-ID: <52F1A6D6.8020801@gmail.com> Date: Wed, 05 Feb 2014 15:49:58 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Michael Richardson References: <52EA3032.3050703@gmail.com> <52EA3361.1010501@gmail.com> <2EB6289E-C7FD-481F-99F9-E35730245943@employees.org> <52EA442D.3020707@gmail.com> <52EA47AA.90302@gmail.com> <1FE00515-A7AD-4C48-A7F2-63BA8696D818@darou.fr> <52EA4BB1.9010607@gmail.com> <2922CC94-540D-4215-899B-4722BD1C5EBC@employees.org> <52EF90BD.4070701@gmail.com> <18C8BE29C547CC4DBBCF3C4F0B8EC1780608ED@wds-exc1.okna.nominet.org.uk> <8B52F0C3-EB5A-48D1-9596-52302F6A4A3C@darou.fr> <8FA52BBD-9A61-4795-9BA3-AB8B0A63EB98@fugue.com> <29DCB6B2-B428-4B45-8796-ACB09E40376A@fugue.com> <26945.1391525921@sandelman.ca> <2BE96E0A-D9A7-492F-B07F-9C83767C6F0D@darou.fr> <445.1391555635@sandelman.ca> In-Reply-To: <445.1391555635@sandelman.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "homenet@ietf.org Group" , Pierre Pfister Subject: Re: [homenet] DHCP PD X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 02:50:02 -0000 On 05/02/2014 12:13, Michael Richardson wrote: > Pierre Pfister wrote: ... >> For instance, if a prefix is for general purpose, and another is for voice >> applications, then hosts may only get addresses for voice application, and >> would therefore not being able to access the internet. Yes, that's one of many reasons why using prefixes to distinguish types of traffic is a really bad idea. Brian From otroan@employees.org Tue Feb 4 23:15:16 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03FB41A0057 for ; Tue, 4 Feb 2014 23:15:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CGTQDcX28fPq for ; Tue, 4 Feb 2014 23:15:15 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id B349A1A0055 for ; Tue, 4 Feb 2014 23:15:14 -0800 (PST) X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggFAMHj8VKQ/khL/2dsb2JhbABZgwy/XIEIFnSCJQEBBAF5EAsOOFcGiBAIzjsXjnUHgySBFAEDkD+aDYMuOw X-IronPort-AV: E=Sophos;i="4.95,785,1384300800"; d="asc'?scan'208";a="4008883" Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-2.cisco.com with ESMTP; 05 Feb 2014 07:15:12 +0000 Received: from dhcp-10-61-101-122.cisco.com (dhcp-10-61-101-122.cisco.com [10.61.101.122]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s157FAr8015246 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 5 Feb 2014 07:15:11 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_31CF89CE-4DA9-42AB-94CE-C5A863EC0B00"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ole Troan In-Reply-To: Date: Wed, 5 Feb 2014 08:15:10 +0100 Message-Id: References: <52EA3032.3050703@gmail.com> <52EA3361.1010501@gmail.com> <2EB6289E-C7FD-481F-99F9-E35730245943@employees.org> <52EA442D.3020707@gmail.com> <52EA47AA.90302@gmail.com> <1FE00515-A7AD-4C48-A7F2-63BA8696D818@darou.fr> <52EA4BB1.9010607@gmail.com> <2922CC94-540D-4215-899B-4722BD1C5EBC@employees.org> <52EF90BD.4070701@gmail.com> <18C8BE29C547CC4DBBCF3C4F0B8EC1780608ED@wds-exc1.okna.nominet.org.uk> <8B52F0C3-EB5A-48D1-9596-52302F6A4A3C@darou.fr> <8FA52BBD-9A61-4795-9BA3-AB8B0A63EB98@fugue.com> <29DCB6B2-B428-4B45-8796-ACB09E40376A@fugue.com> To: Ted Lemon X-Mailer: Apple Mail (2.1827) Cc: Alexandru Petrescu , Markus Stenberg , Ray Bellis , Pierre Pfister , "homenet@ietf.org Group" , Lorenzo Colitti Subject: Re: [homenet] DHCP PD X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 07:15:16 -0000 --Apple-Mail=_31CF89CE-4DA9-42AB-94CE-C5A863EC0B00 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Ted, >> I thought you were asking for host changes to support multiple = servers (even if RFC says they should, and I=92m not sure it does, I = have yet to find one that does). >=20 > I think host changes to make this work will be crucial to having hosts = that can operate on multiple prefixes managed by different organizations = on the same wire, but I don't think that homenet clients need this, = because most likely they'll be doing SLAAC, and maybe getting some local = configuration parameters with stateless DHCP, which themselves would = have to be derived automatically by the homenet, either through internal = communication or from externally-received information. yes, and with the "derived automatically" mechanism you could also use = DHCP for address assignment. the homenet side of the routers "managed by different organisations" = would of course have to be managed (or non-managed) by the homenet = itself. cheers, Ole --Apple-Mail=_31CF89CE-4DA9-42AB-94CE-C5A863EC0B00 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJS8eT+AAoJEFuJXizso86g6AkH/3w5BIZ+Sk6uVVRzuk2lc4/m FJ8rn9BIiroyPEa2tS+nkkrYO9H2esmlsYx7bUP73D4FQfSTJEuPIjP9TvHyJjFi rTSRp4pSi9Vn7UzsK3dYvjsziHaAV41m8Ni3iWRh0HHuHjCqn94g3kBY54Z4jAuv pCYJh003zvIY006z9nsZSZ3iBCeqzi3JSaSdgDhUDscYqs5hNSSZZ6zRAUkrCF0a IH8XLdIh4Ww0Fy5O7fqIxeEHUIkQKDMn100oLV2NlxUHrxs4t2s8SrGJuOYL7ehl 6NeLMca6PdotyTAQMQYld6Wvss3H3RWwNcN5YjW3ug+EtPV2F/Hb1KIxMbs/shA= =b5jU -----END PGP SIGNATURE----- --Apple-Mail=_31CF89CE-4DA9-42AB-94CE-C5A863EC0B00-- From otroan@employees.org Wed Feb 5 00:04:55 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60CE71A00A7 for ; Wed, 5 Feb 2014 00:04:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id THj-t3KpEn99 for ; Wed, 5 Feb 2014 00:04:54 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id B304C1A0063 for ; Wed, 5 Feb 2014 00:04:53 -0800 (PST) X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAAjw8VKQ/khM/2dsb2JhbABZgww4vySBCBZ0giUBAQQBeRALDjhXBi6HYggNzj0XjnUHgySBFASQP4kekG+DLjs X-IronPort-AV: E=Sophos;i="4.95,785,1384300800"; d="asc'?scan'208";a="4677789" Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-1.cisco.com with ESMTP; 05 Feb 2014 08:04:52 +0000 Received: from dhcp-10-61-101-122.cisco.com (dhcp-10-61-101-122.cisco.com [10.61.101.122]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s1584oae029155 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 5 Feb 2014 08:04:51 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_5B9AA376-DBE6-4BAC-BBBB-AFA285468801"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ole Troan In-Reply-To: Date: Wed, 5 Feb 2014 09:04:50 +0100 Message-Id: <86B24348-21AE-43A8-BF16-555EB566BE72@employees.org> References: <52EA3032.3050703@gmail.com> <52EA3361.1010501@gmail.com> <2EB6289E-C7FD-481F-99F9-E35730245943@employees.org> <52EA442D.3020707@gmail.com> <52EA47AA.90302@gmail.com> <1FE00515-A7AD-4C48-A7F2-63BA8696D818@darou.fr> <52EA4BB1.9010607@gmail.com> <2922CC94-540D-4215-899B-4722BD1C5EBC@employees.org> <52EF90BD.4070701@gmail.com> <18C8BE29C547CC4DBBCF3C4F0B8EC1780608ED@wds-exc1.okna.nominet.org.uk> <8B52F0C3-EB5A-48D1-9596-52302F6A4A3C@darou.fr> <8FA52BBD-9A61-4795-9BA3-AB8B0A63EB98@fugue.com> <29DCB6B2-B428-4B45-8796-ACB09E40376A@fugue.com> <8FB38433-5358-4172-968C-76564A875520@employees.org> To: Ted Lemon X-Mailer: Apple Mail (2.1827) Cc: Alexandru Petrescu , Markus Stenberg , Ray Bellis , Pierre Pfister , "homenet@ietf.org Group" , Lorenzo Colitti Subject: Re: [homenet] DHCP PD X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 08:04:55 -0000 --Apple-Mail=_5B9AA376-DBE6-4BAC-BBBB-AFA285468801 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Ted, >> actually, we're talking about prefix assignment. which may be = splitting hairs, but isn't quite the same as prefix delegation. >=20 > Splain? You mean we're talking about the general problem, rather = than the DHCP-PD solution? If so, that's fine, but the specific = comment that Markus made was about DHCP PD, and that's what I was = responding to. I am not specifically advocating the use of DHCP PD to = solve this problem, but I do want to see it evaluated realistically, and = not on the basis of a misunderstanding of what it does and how it's = used. as one of the authors of RFC3633, DHCP PD was not designed to do = assignment of prefixes inside a network. DHCP PD was designed to be a "fax replacement". there has been a number of proposals for how DHCP PD could be adapted = for this purpose: they generally fall into one of flat assignment with central DHCP server = or hierarchical PD with a spanning tree of DHCP relays. http://tools.ietf.org/html/draft-baker-homenet-prefix-assignment-01 http://tools.ietf.org/html/draft-chakrabarti-homenet-prefix-alloc-01 http://tools.ietf.org/html/draft-gmann-homenet-relay-autoconf-01 http://tools.ietf.org/html/draft-grundemann-hipnet-00 please take a look at those drafts, and let us know what we've missed in = the DHCP PD "solution space". cheers, Ole --Apple-Mail=_5B9AA376-DBE6-4BAC-BBBB-AFA285468801 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJS8fCiAAoJEFuJXizso86gjSgH/0JNdHowUcGtsnW3h2SumQE+ LTyoBoT7vExpYpChT1XLeeM8S4+pXv/YSlcTIp7JwHg1gKQhDkHstwWOtdjR5f0Z 4iaoDcCPEUyLb1u0ULbDvRriIVbzWBVF3QJDkVqyFV0r42ZAhcd2SqmUVDATT39H R/VOzf9IGeOKNb4LcLYhDMY6zdGIfrIuIvInf4rah1WUqVTxQNGodNE2aI1B7BbH NtbkCiYImHQLCskdoa+cueyNlXvLcnJ69IWFqA7xr2c43WOf3vOEtyZlht4dtNwc +0SNHhja8106RBr8Vn2w2Jk+pdG7nTBj46FYQp2tO9bFjUsQ8UKoxWkInWgYGls= =JI2h -----END PGP SIGNATURE----- --Apple-Mail=_5B9AA376-DBE6-4BAC-BBBB-AFA285468801-- From swmike@swm.pp.se Wed Feb 5 00:06:58 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 567861A00AD for ; Wed, 5 Feb 2014 00:06:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.386 X-Spam-Level: X-Spam-Status: No, score=-4.386 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38dIhAQAOtu0 for ; Wed, 5 Feb 2014 00:06:55 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by ietfa.amsl.com (Postfix) with ESMTP id 984F11A0063 for ; Wed, 5 Feb 2014 00:06:55 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 393D99C; Wed, 5 Feb 2014 09:06:54 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 345379A; Wed, 5 Feb 2014 09:06:54 +0100 (CET) Date: Wed, 5 Feb 2014 09:06:54 +0100 (CET) From: Mikael Abrahamsson To: Brian E Carpenter In-Reply-To: <52F1A6D6.8020801@gmail.com> Message-ID: References: <52EA3032.3050703@gmail.com> <52EA3361.1010501@gmail.com> <2EB6289E-C7FD-481F-99F9-E35730245943@employees.org> <52EA442D.3020707@gmail.com> <52EA47AA.90302@gmail.com> <1FE00515-A7AD-4C48-A7F2-63BA8696D818@darou.fr> <52EA4BB1.9010607@gmail.com> <2922CC94-540D-4215-899B-4722BD1C5EBC@employees.org> <52EF90BD.4070701@gmail.com> <18C8BE29C547CC4DBBCF3C4F0B8EC1780608ED@wds-exc1.okna.nominet.org.uk> <8B52F0C3-EB5A-48D1-9596-52302F6A4A3C@darou.fr> <8FA52BBD-9A61-4795-9BA3-AB8B0A63EB98@fugue.com> <29DCB6B2-B428-4B45-8796-ACB09E40376A@fugue.com> <26945.1391525921@sandelman.ca> <2BE96E0A-D9A7-492F-B07F-9C83767C6F0D@darou.fr> <445.1391555635@sandelman.ca> <52F1A6D6.8020801@gmail.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "homenet@ietf.org Group" Subject: Re: [homenet] DHCP PD X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 08:06:58 -0000 On Wed, 5 Feb 2014, Brian E Carpenter wrote: > On 05/02/2014 12:13, Michael Richardson wrote: >> Pierre Pfister wrote: > ... >>> For instance, if a prefix is for general purpose, and another is for voice >>> applications, then hosts may only get addresses for voice application, and >>> would therefore not being able to access the internet. > > Yes, that's one of many reasons why using prefixes to distinguish > types of traffic is a really bad idea. The idea is that "non color-aware" devices will only use the "Internet" prefix, by means of the colored prefixes will use a different ND PIO type for prefix announcement (thus invisible to these non color-aware hosts), plus DHCPv6 server would only hand out prefixes/addresses to hosts that request them. -- Mikael Abrahamsson email: swmike@swm.pp.se From alexandru.petrescu@gmail.com Wed Feb 5 04:04:54 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF6851A00F6 for ; Wed, 5 Feb 2014 04:04:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IIdC-PuTytki for ; Wed, 5 Feb 2014 04:04:52 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 763A41A00F1 for ; Wed, 5 Feb 2014 04:04:52 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s15C4Kbj015365; Wed, 5 Feb 2014 13:04:20 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E614E203087; Wed, 5 Feb 2014 13:04:40 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id CC7BE202ECC; Wed, 5 Feb 2014 13:04:40 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s15C4Elh022512; Wed, 5 Feb 2014 13:04:20 +0100 Message-ID: <52F228BE.7010503@gmail.com> Date: Wed, 05 Feb 2014 13:04:14 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Ole Troan , Ted Lemon References: <52EA3361.1010501@gmail.com> <2EB6289E-C7FD-481F-99F9-E35730245943@employees.org> <52EA442D.3020707@gmail.com> <52EA47AA.90302@gmail.com> <1FE00515-A7AD-4C48-A7F2-63BA8696D818@darou.fr> <52EA4BB1.9010607@gmail.com> <2922CC94-540D-4215-899B-4722BD1C5EBC@employees.org> <52EF90BD.4070701@gmail.com> <18C8BE29C547CC4DBBCF3C4F0B8EC1780608ED@wds-exc1.okna.nominet.org.uk> <8B52F0C3-EB5A-48D1-9596-52302F6A4A3C@darou.fr> <8FA52BBD-9A61-4795-9BA3-AB8B0A63EB98@fugue.com> <29DCB6B2-B428-4B45-8796-ACB09E40376A@fugue.com> <8FB38433-5358-4172-968C-76564A875520@employees.org> <86B24348-21AE-43A8-BF16-555EB566BE72@employees.org> In-Reply-To: <86B24348-21AE-43A8-BF16-555EB566BE72@employees.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: Ray Bellis , "homenet@ietf.org Group" , Markus Stenberg , Pierre Pfister , Lorenzo Colitti Subject: Re: [homenet] DHCP PD X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 12:04:55 -0000 Le 05/02/2014 09:04, Ole Troan a écrit : > Ted, > >>> actually, we're talking about prefix assignment. which may be >>> splitting hairs, but isn't quite the same as prefix delegation. >> >> Splain? You mean we're talking about the general problem, rather >> than the DHCP-PD solution? If so, that's fine, but the specific >> comment that Markus made was about DHCP PD, and that's what I was >> responding to. I am not specifically advocating the use of DHCP >> PD to solve this problem, but I do want to see it evaluated >> realistically, and not on the basis of a misunderstanding of what >> it does and how it's used. > > as one of the authors of RFC3633, DHCP PD was not designed to do > assignment of prefixes inside a network. DHCP PD was designed to be a > "fax replacement". That may be one of the original intents, I dont doubt it, and I am happy to see it that way (although I wonder what in a fax uses prefixes). And I disagree with the statement that DHCP PD to be just a quote fax replacement. It's been also used for moving networks, like in RFC6276 and in the upcoming to some extent it a 'proxy' form. > there has been a number of proposals for how DHCP PD could be adapted > for this purpose: > > they generally fall into one of flat assignment with central DHCP > server or hierarchical PD with a spanning tree of DHCP relays. > > http://tools.ietf.org/html/draft-baker-homenet-prefix-assignment-01 > http://tools.ietf.org/html/draft-chakrabarti-homenet-prefix-alloc-01 > http://tools.ietf.org/html/draft-gmann-homenet-relay-autoconf-01 > http://tools.ietf.org/html/draft-grundemann-hipnet-00 > > please take a look at those drafts, and let us know what we've missed > in the DHCP PD "solution space". The picture is interesting and one would have to look at them. I would specifically look for whether they suggest means to dynamically configure the relationship between the Relay and the Server. Alex > > cheers, Ole > From alexandru.petrescu@gmail.com Wed Feb 5 04:13:41 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC671A00FA for ; Wed, 5 Feb 2014 04:13:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jY_0akKChawy for ; Wed, 5 Feb 2014 04:13:39 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id F29A51A00F6 for ; Wed, 5 Feb 2014 04:13:38 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s15CDbZh020336 for ; Wed, 5 Feb 2014 13:13:37 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 1ADE1202ECC for ; Wed, 5 Feb 2014 13:13:58 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 1326B200D2F for ; Wed, 5 Feb 2014 13:13:58 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s15CDaWA028006 for ; Wed, 5 Feb 2014 13:13:37 +0100 Message-ID: <52F22AF1.6060300@gmail.com> Date: Wed, 05 Feb 2014 13:13:37 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: homenet@ietf.org References: <52EA3361.1010501@gmail.com> <2EB6289E-C7FD-481F-99F9-E35730245943@employees.org> <52EA442D.3020707@gmail.com> <52EA47AA.90302@gmail.com> <1FE00515-A7AD-4C48-A7F2-63BA8696D818@darou.fr> <52EA4BB1.9010607@gmail.com> <2922CC94-540D-4215-899B-4722BD1C5EBC@employees.org> <52EF90BD.4070701@gmail.com> <18C8BE29C547CC4DBBCF3C4F0B8EC1780608ED@wds-exc1.okna.nominet.org.uk> <8B52F0C3-EB5A-48D1-9596-52302F6A4A3C@darou.fr> <8FA52BBD-9A61-4795-9BA3-AB8B0A63EB98@fugue.com> <29DCB6B2-B428-4B45-8796-ACB09E40376A@fugue.com> <26945.1391525921@sandelman.ca> <2BE96E0A-D9A7-492F-B07F-9C83767C6F0D@darou.fr> <445.1391555635@sandelman.ca> <52F1A6D6.8020801@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [homenet] DHCP PD X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 12:13:41 -0000 Le 05/02/2014 09:06, Mikael Abrahamsson a écrit : > On Wed, 5 Feb 2014, Brian E Carpenter wrote: > >> On 05/02/2014 12:13, Michael Richardson wrote: >>> Pierre Pfister wrote: >> ... >>>> For instance, if a prefix is for general purpose, and another is for >>>> voice >>>> applications, then hosts may only get addresses for voice >>>> application, and >>>> would therefore not being able to access the internet. >> >> Yes, that's one of many reasons why using prefixes to distinguish >> types of traffic is a really bad idea. > > The idea is that "non color-aware" devices will only use the "Internet" > prefix, by means of the colored prefixes will use a different ND PIO > type for prefix announcement (thus invisible to these non color-aware > hosts), plus DHCPv6 server would only hand out prefixes/addresses to > hosts that request them. A color could also be a particular value for the flow label field. Alex > From mellon@fugue.com Wed Feb 5 05:08:41 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 603191A011B for ; Wed, 5 Feb 2014 05:08:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w2yjLXOOoFBS for ; Wed, 5 Feb 2014 05:08:38 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 8F9271A0116 for ; Wed, 5 Feb 2014 05:08:38 -0800 (PST) Received: from [10.0.10.40] (c-174-62-147-182.hsd1.nh.comcast.net [174.62.147.182]) by toccata.fugue.com (Postfix) with ESMTPSA id 2019123803AB; Wed, 5 Feb 2014 08:08:35 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ted Lemon In-Reply-To: <86B24348-21AE-43A8-BF16-555EB566BE72@employees.org> Date: Wed, 5 Feb 2014 08:08:34 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1A7874B2-90B5-4C02-9AAE-510B5CC4E98B@fugue.com> References: <52EA3032.3050703@gmail.com> <52EA3361.1010501@gmail.com> <2EB6289E-C7FD-481F-99F9-E35730245943@employees.org> <52EA442D.3020707@gmail.com> <52EA47AA.90302@gmail.com> <1FE00515-A7AD-4C48-A7F2-63BA8696D818@darou.fr> <52EA4BB1.9010607@gmail.com> <2922CC94-540D-4215-899B-4722BD1C5EBC@employees.org> <52EF90BD.4070701@gmail.com> <18C8BE29C547CC4DBBCF3C4F0B8EC1780608ED@wds-exc1.okna.nominet.org.uk> <8B52F0C3-EB5A-48D1-9596-52302F6A4A3C@darou.fr> <8FA52BBD-9A61-4795-9BA3-AB8B0A63EB98@fugue.com> <29DCB6B2-B428-4B45-8796-ACB09E40376A@fugue.com> <8FB38433-5358-4172-968C-76564A875520@employees.org> <86B24348-2 1AE-43A8-BF16-555EB566BE72@employees.org> To: Ole Troan X-Mailer: Apple Mail (2.1827) Cc: Alexandru Petrescu , Markus Stenberg , Ray Bellis , Pierre Pfister , "homenet@ietf.org Group" , Lorenzo Colitti Subject: Re: [homenet] DHCP PD X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 13:08:41 -0000 On Feb 5, 2014, at 3:04 AM, Ole Troan wrote: > please take a look at those drafts, and let us know what we've missed = in the DHCP PD "solution space". I've read all those drafts at one time or another. I just checked the = latest version of = http://tools.ietf.org/html/draft-gmann-homenet-relay-autoconf and it = appears to do pretty much the right thing. One thing that isn't mentioned in that draft that I don't think is = intuitive to all readers is that if you have two CERs, this technique = still works; the only difference is that the technique has to be done = independently by each internal router with respect to each CER. This draft also does not appear to talk about how to get rid of prefixes = to CERs that have failed. Ideally the homenet routing protocol server = could signal the DHCPv6 PD requesting router server when a CER has gone = away, or else the PD requesting router server could poll for that = information from time to time (you want a little hysteresis to avoid = needlessly dropping prefixes in the event of a router reboot, of = course). From otroan@employees.org Wed Feb 5 06:01:10 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0E8D1A015D for ; Wed, 5 Feb 2014 06:01:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0afnsbx1RTWq for ; Wed, 5 Feb 2014 06:01:08 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 2DFFF1A0151 for ; Wed, 5 Feb 2014 06:01:08 -0800 (PST) X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAP1C8lKQ/khN/2dsb2JhbABZgww4vxqBDxZ0giUBAQQBJ1IFCwsOOFcGLodiCA3PNxeOCmsHgySBFASQP4kekG+DLjs X-IronPort-AV: E=Sophos;i="4.95,786,1384300800"; d="asc'?scan'208";a="4028642" Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-2.cisco.com with ESMTP; 05 Feb 2014 14:01:06 +0000 Received: from dhcp-10-61-104-210.cisco.com (dhcp-10-61-104-210.cisco.com [10.61.104.210]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s15E11Tt005715 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 5 Feb 2014 14:01:03 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_E42FC559-7F83-4613-B25C-A19BB4B84923"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ole Troan In-Reply-To: <1A7874B2-90B5-4C02-9AAE-510B5CC4E98B@fugue.com> Date: Wed, 5 Feb 2014 15:01:01 +0100 Message-Id: <73E60BBE-35C3-41D3-81AF-139A99C3D5DF@employees.org> References: <52EA3032.3050703@gmail.com> <52EA3361.1010501@gmail.com> <2EB6289E-C7FD-481F-99F9-E35730245943@employees.org> <52EA442D.3020707@gmail.com> <52EA47AA.90302@gmail.com> <1FE00515-A7AD-4C48-A7F2-63BA8696D818@darou.fr> <52EA4BB1.9010607@gmail.com> <2922CC94-540D-4215-899B-4722BD1C5EBC@employees.org> <52EF90BD.4070701@gmail.com> <18C8BE29C547CC4DBBCF3C4F0B8EC1780608ED@wds-exc1.okna.nominet.org.uk> <8B52F0C3-EB5A-48D1-9596-52302F6A4A3C@darou.fr> <8FA52BBD-9A61-4795-9BA3-AB8B0A63EB98@fugue.com> <29DCB6B2-B428-4B45-8796-ACB09E40376A@fugue.com> <8FB38433-5358-4172-968C-76564A875520@employees.org> <86B24348-2 1AE-43A 8-BF16-555EB566BE72@employees.org> <1A7874B2-90B5-4C02-9AAE-510B5CC4E98B@fugue.com> To: Ted Lemon X-Mailer: Apple Mail (2.1827) Cc: Alexandru Petrescu , Markus Stenberg , Ray Bellis , Pierre Pfister , "homenet@ietf.org Group" , Lorenzo Colitti Subject: Re: [homenet] DHCP PD X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 14:01:10 -0000 --Apple-Mail=_E42FC559-7F83-4613-B25C-A19BB4B84923 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Ted, >> please take a look at those drafts, and let us know what we've missed = in the DHCP PD "solution space". >=20 > I've read all those drafts at one time or another. I just checked = the latest version of = http://tools.ietf.org/html/draft-gmann-homenet-relay-autoconf and it = appears to do pretty much the right thing. >=20 > One thing that isn't mentioned in that draft that I don't think is = intuitive to all readers is that if you have two CERs, this technique = still works; the only difference is that the technique has to be done = independently by each internal router with respect to each CER. you make it sound like that's a part and parcel of DHCP. I can't see how = you can implement that today. are there any implementations doing this? I have never seen any. as an example of the problems you'll encounter. how does the RR detect = the difference between a backup DR and a separate DR? first case it = should pick the best server, second case it should set up sessions to = both. > This draft also does not appear to talk about how to get rid of = prefixes to CERs that have failed. Ideally the homenet routing = protocol server could signal the DHCPv6 PD requesting router server when = a CER has gone away, or else the PD requesting router server could poll = for that information from time to time (you want a little hysteresis to = avoid needlessly dropping prefixes in the event of a router reboot, of = course). "homenet routing protocol server"? this proposal makes do with static = routing. given an arbitrary topology. how do you build the relay topology and discover DHCP servers? use site-local multicast -> we don=92t quite know how to bootstrap = that? hop-by-hop relaying? how do you deal with loops? you're essentially building a spanning tree of relays. how do you deal with multiple routers on the link? just keep adding /64s = out of the same site-prefix to it? how does the network react to network events? given you rely on DHCP = snooping then network convergence time is rather glacial. while DHCP PD may look like a candidate at first glance, to make it work = in all corner cases, you essentially build something quite different = than current DHCP. then you might as well use a real routing protocol = and a prefix assignment protocol designed for the purpose. cheers, Ole --Apple-Mail=_E42FC559-7F83-4613-B25C-A19BB4B84923 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJS8kQdAAoJEFuJXizso86g92UIAKUeIXmTHCBiJ7n7eMRNswtN Wy8PZUWD3/Td/4gUXtt4S5uYyn6IMXrKExdwFnne0W0SBBwaqrMStmUEC4NYBtdO NrcNETqYa831RlTMCR/7J/GWqSIpmba1z+y++53xL1XL0HWhyskB26zk4Glvau8X Tic1xCPqS1GmExrKUCkYGoEHtDXfKPy5ZOrhwxQQIWPDPb+U4xhFJ/VXEk6zww+G 8L9zb5NYri2NI+qBhNgLYbM/AOZnbXXTzjhL+W7vrMuw3Q1p9FG7rshtq/CK//Qq u3Rc0RiMOAWrLC4VjDNz8oCDVKtdmtk6otMYlf3vFhhEDObHWpvuzukNaD7GV1k= =yo9n -----END PGP SIGNATURE----- --Apple-Mail=_E42FC559-7F83-4613-B25C-A19BB4B84923-- From mellon@fugue.com Wed Feb 5 06:13:07 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE23B1A0153 for ; Wed, 5 Feb 2014 06:13:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YZL8IvrVZrJx for ; Wed, 5 Feb 2014 06:13:05 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 984411A0147 for ; Wed, 5 Feb 2014 06:13:05 -0800 (PST) Received: from [10.0.10.40] (c-174-62-147-182.hsd1.nh.comcast.net [174.62.147.182]) by toccata.fugue.com (Postfix) with ESMTPSA id 1274023803AB; Wed, 5 Feb 2014 09:13:02 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ted Lemon In-Reply-To: <73E60BBE-35C3-41D3-81AF-139A99C3D5DF@employees.org> Date: Wed, 5 Feb 2014 09:13:01 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <5910DE0B-4E61-4A92-9EAF-7983E4BDB80E@fugue.com> References: <52EA3032.3050703@gmail.com> <52EA3361.1010501@gmail.com> <2EB6289E-C7FD-481F-99F9-E35730245943@employees.org> <52EA442D.3020707@gmail.com> <52EA47AA.90302@gmail.com> <1FE00515-A7AD-4C48-A7F2-63BA8696D818@darou.fr> <52EA4BB1.9010607@gmail.com> <2922CC94-540D-4215-899B-4722BD1C5EBC@employees.org> <52EF90BD.4070701@gmail.com> <18C8BE29C547CC4DBBCF3C4F0B8EC1780608ED@wds-exc1.okna.nominet.org.uk> <8B52F0C3-EB5A-48D1-9596-52302F6A4A3C@darou.fr> <8FA52BBD-9A61-4795-9BA3-AB8B0A63EB98@fugue.com> <29DCB6B2-B428-4B45-8796-ACB09E40376A@fugue.com> <8FB38433-5358-4172-968C-76564A875520@employees.org> <86B24348-2 1AE-43A 8-BF16-555EB566BE72@employees.org> <1A7874B2-90B5-4C02-9AAE-510B5CC4E98B@fugue.com> <73E60BBE-35C3-41D3-81AF-139A99C3D5DF@employees.org> To: Ole Troan X-Mailer: Apple Mail (2.1827) Cc: Alexandru Petrescu , Markus Stenberg , Ray Bellis , Pierre Pfister , "homenet@ietf.org Group" , Lorenzo Colitti Subject: Re: [homenet] DHCP PD X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 14:13:08 -0000 On Feb 5, 2014, at 9:01 AM, Ole Troan wrote: > you make it sound like that's a part and parcel of DHCP. I can't see = how you can implement that today. Eh? It's dead trivial. The draft already sets up relay agents=97the = only difference is that all relays now relay to both CERs, not just one. = The requesting routers get delegations from both CERs and use both = delegations. You are right that no existing implementation does this, but no existing = implementation does homenet, so that seems like a pretty mild criticism! = :) > "homenet routing protocol server"? this proposal makes do with static = routing. When I said the proposal looked mostly right, I was referring to the = DHCP PD aspect, not the static routing aspect. Static routing might = work, but I suspect it would be brittle. > how do you deal with multiple routers on the link? just keep adding = /64s out of the same site-prefix to it? Only the CERs delegate prefixes. If you have multiple paths to the same = CER, you will still only get one prefix per identity association. > how does the network react to network events? given you rely on DHCP = snooping then network convergence time > is rather glacial. Right, I'm not arguing that we don't need a routing protocol. I'm not = even particularly arguing that PD is the right way to delegate prefixes. = But it would work, and with no protocol changes=97it would just = require an operations document to explain how to do it. From otroan@employees.org Wed Feb 5 06:33:34 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C5871A0198 for ; Wed, 5 Feb 2014 06:33:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IkpiKe-Auffs for ; Wed, 5 Feb 2014 06:33:33 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 11F761A0180 for ; Wed, 5 Feb 2014 06:33:32 -0800 (PST) X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAFhL8lKQ/khR/2dsb2JhbABQCYMMv1KBDhZ0giUBAQQBeQULCw44VwaIEAjPRxeOGlsHgySBFAEDkD+aDYMuOw X-IronPort-AV: E=Sophos;i="4.95,786,1384300800"; d="asc'?scan'208";a="4030041" Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-2.cisco.com with ESMTP; 05 Feb 2014 14:33:31 +0000 Received: from dhcp-10-61-104-210.cisco.com (dhcp-10-61-104-210.cisco.com [10.61.104.210]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s15EXPrf032446 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 5 Feb 2014 14:33:27 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_C24F94B6-1B2A-4981-B97C-CE084A2890FC"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ole Troan In-Reply-To: <5910DE0B-4E61-4A92-9EAF-7983E4BDB80E@fugue.com> Date: Wed, 5 Feb 2014 15:33:24 +0100 Message-Id: <61D81364-897D-4CA6-9326-C795B6DFB09A@employees.org> References: <52EA3032.3050703@gmail.com> <52EA3361.1010501@gmail.com> <2EB6289E-C7FD-481F-99F9-E35730245943@employees.org> <52EA442D.3020707@gmail.com> <52EA47AA.90302@gmail.com> <1FE00515-A7AD-4C48-A7F2-63BA8696D818@darou.fr> <52EA4BB1.9010607@gmail.com> <2922CC94-540D-4215-899B-4722BD1C5EBC@employees.org> <52EF90BD.4070701@gmail.com> <18C8BE29C547CC4DBBCF3C4F0B8EC1780608ED@wds-exc1.okna.nominet.org.uk> <8B52F0C3-EB5A-48D1-9596-52302F6A4A3C@darou.fr> <8FA52BBD-9A61-4795-9BA3-AB8B0A63EB98@fugue.com> <29DCB6B2-B428-4B45-8796-ACB09E40376A@fugue.com> <8FB38433-5358-4172-968C-76564A875520@employees.org> <86B24348-2 1AE-43A 8-BF16-555EB566BE72@employees.org> <1A7874B2-90B5-4C02-9AAE-510B5CC4E98B@fugue.com> <73E60BBE-35C3-41D3-81AF-139A99C3D5DF@employees.org> <5910DE0B-4E61-4A92-9EAF-7983E4BDB80E@fugue.com> To: Ted Lemon X-Mailer: Apple Mail (2.1827) Cc: Alexandru Petrescu , Markus Stenberg , Ray Bellis , Pierre Pfister , "homenet@ietf.org Group" , Lorenzo Colitti Subject: Re: [homenet] DHCP PD X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 14:33:34 -0000 --Apple-Mail=_C24F94B6-1B2A-4981-B97C-CE084A2890FC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Ted, >> you make it sound like that's a part and parcel of DHCP. I can't see = how you can implement that today. >=20 > Eh? It's dead trivial. The draft already sets up relay agents=97the = only difference is that all relays now relay to both CERs, not just one. = The requesting routers get delegations from both CERs and use both = delegations. you cut out my question about how to build the relay topology. e.g. relays would have to replicate client messages to multiple CERs. > You are right that no existing implementation does this, but no = existing implementation does homenet, so that seems like a pretty mild = criticism! :) a goal for homenet is to reuse existing implementations. >> "homenet routing protocol server"? this proposal makes do with static = routing. >=20 > When I said the proposal looked mostly right, I was referring to the = DHCP PD aspect, not the static routing aspect. Static routing might = work, but I suspect it would be brittle. >=20 >> how do you deal with multiple routers on the link? just keep adding = /64s out of the same site-prefix to it? >=20 > Only the CERs delegate prefixes. If you have multiple paths to the = same CER, you will still only get one prefix per identity association. a link with multiple routers on it will get multiple prefixes from the = same site prefix. >> how does the network react to network events? given you rely on DHCP = snooping then network convergence time >> is rather glacial. >=20 > Right, I'm not arguing that we don't need a routing protocol. I'm = not even particularly arguing that PD is the right way to delegate = prefixes. But it would work, and with no protocol changes=97it would = just require an operations document to explain how to do it. I see you are making that assertion. I don't believe you. please write a draft how this would work. cheers, Ole --Apple-Mail=_C24F94B6-1B2A-4981-B97C-CE084A2890FC Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJS8ku0AAoJEFuJXizso86gK4YIAJf6aEb0IoExtB7RS1jVx5/f ML0Pmg4qz4/4CzjDkONMettflKgK9sV2if3jelqUUYhVB225XOtZA/R2RBmqXDnA 6uXp5OTZQDMznbBclb0tTCmtepXawyr2WPwwMLrVetGzsqD/dIzVa1NMsjg9XSSp OG64qCnHHVtcUUomEJ6Ydm7AmEtBc3KJ4qY805cwvEhyo0uzXBs5W92eft5Mo4um FkY1yLJEppkW4xxCGra0uNaXZ5WOH1pIogWIrGzGfwAkwhLppKWepOUPWbNeW1qZ miDTjcE17yclr9E+99+1JVjlqD1Kix+LKUb9euIV/m3WSZcrdyFLHnV+NkOf770= =0/gU -----END PGP SIGNATURE----- --Apple-Mail=_C24F94B6-1B2A-4981-B97C-CE084A2890FC-- From markus.stenberg@iki.fi Wed Feb 5 06:52:27 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 651A71A018C for ; Wed, 5 Feb 2014 06:52:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40H16DMc5Tkd for ; Wed, 5 Feb 2014 06:52:25 -0800 (PST) Received: from jenni1.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 619BA1A0186 for ; Wed, 5 Feb 2014 06:52:25 -0800 (PST) Received: from kosame.lan (80.220.67.193) by jenni1.inet.fi (8.5.140.03) (authenticated as stenma-47) id 527750DA07C4F1C7; Wed, 5 Feb 2014 16:52:23 +0200 From: Markus Stenberg Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Wed, 5 Feb 2014 16:52:09 +0200 Message-Id: <58809B4D-CCE4-4DAC-9A1A-DD475584E65B@iki.fi> To: "homenet@ietf.org Group" Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) X-Mailer: Apple Mail (2.1827) Cc: Markus Stenberg Subject: [homenet] Two new drafts (and third one 'soon') X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 14:52:27 -0000 Drafts: http://tools.ietf.org/html/draft-stenberg-homenet-hncp-00 = http://tools.ietf.org/html/draft-stenberg-homenet-dnssd-hybrid-proxy-zeroc= onf-00 (Generic PA one in the works, but submitted also =92soon=92) Experimental partial implementation: https://github.com/sbyx/hnetd/ Discuss. Cheers, -Markus= From teco@inf-net.nl Wed Feb 5 08:19:53 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 210DE1A00E2 for ; Wed, 5 Feb 2014 08:19:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qBWZNlUUYQ-z for ; Wed, 5 Feb 2014 08:19:50 -0800 (PST) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by ietfa.amsl.com (Postfix) with ESMTP id F08FF1A00EE for ; Wed, 5 Feb 2014 08:19:49 -0800 (PST) Received: by mail-wi0-f182.google.com with SMTP id f8so721339wiw.9 for ; Wed, 05 Feb 2014 08:19:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=Zk+aE7wcoUxScVs7nF1p19BhFNRViT7D3b4B2hu1sU4=; b=kPf2jCIlkonmY6DtlchAupf8AnB1UK3ycR7pBGCd/DpfRvZFhkodm3XSM0y+CQBXEG fNMUJWng0EwtDeEPPqMQtYN0MdWr+eJ1cUgQ6g4xOXPALhNaJdXTV+2m/43TiEGtzQTE yn8QRlDGT3JOaOufBP1chpekdvYMQxn1fdtnddbdMPe+wRWPwHnJq/Og2opDMPz5RBCa TuFUE82YVu7tzJfZZPOMjcfioLV4UHUDFg+0xLHfXr+SielQkjeorsU8txITU0r1pWac O0wkqQ9y2rpjaFbsCSdhIcngFZj9bkYRYyoMU/TQNEa7twODMKNvNNtW59KmXyVrDM/r 8w5g== X-Gm-Message-State: ALoCoQnFS7XVmIke4wreZ5R9zS8vNbonPURE2UDjWSeU8ZYx+YRil+trTGGYsAf8V+YfzEpWF+gl X-Received: by 10.180.107.1 with SMTP id gy1mr3146785wib.47.1391617188225; Wed, 05 Feb 2014 08:19:48 -0800 (PST) Received: from [172.20.10.3] ([84.241.212.165]) by mx.google.com with ESMTPSA id u6sm47065834wif.6.2014.02.05.08.19.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Feb 2014 08:19:46 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Teco Boot In-Reply-To: <61D81364-897D-4CA6-9326-C795B6DFB09A@employees.org> Date: Wed, 5 Feb 2014 16:57:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <86D16466-42C7-400D-A6B6-E257748F21FD@inf-net.nl> References: <52EA3032.3050703@gmail.com> <52EA3361.1010501@gmail.com> <2EB6289E-C7FD-481F-99F9-E35730245943@employees.org> <52EA442D.3020707@gmail.com> <52EA47AA.90302@gmail.com> <1FE00515-A7AD-4C48-A7F2-63BA8696D818@darou.fr> <52EA4BB1.9010607@gmail.com> <2922CC94-540D-4215-899B-4722BD1C5EBC@employees.org> <52EF90BD.4070701@gmail.com> <18C8BE29C547CC4DBBCF3C4F0B8EC1780608ED@wds-exc1.okna.nominet.org.uk> <8B52F0C3-EB5A-48D1-9596-52302F6A4A3C@darou.fr> <8FA52BBD-9A61-4795-9BA3-AB8B0A63EB98@fugue.com> <29DCB6B2-B428-4B45-8796-ACB09E40376A@fugue.com> <8FB38433-5358-4172-968C-76564A875520@employees.org> <86B24348-2 1AE-43A 8-BF16-555EB566BE72@employees.org> <1A7874B2-90B5-4C02-9AAE-510B5CC4E98B@fugue.com> <73E60BBE-35C3-41D3-81AF-139A99C3D5DF@employees.org> <5910DE0B-4E61-4A92-9EAF-7983E4BDB80E@fugue.com> <61D81364-897D-4CA6-9326-C795B6DFB09A@employees.org> To: Ole Troan X-Mailer: Apple Mail (2.1827) Cc: Alexandru Petrescu , Markus Stenberg , Ted Lemon , Ray Bellis , Pierre Pfister , "homenet@ietf.org Group" , Lorenzo Colitti Subject: Re: [homenet] DHCP PD X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 16:19:53 -0000 Op 5 feb. 2014, om 15:33 heeft Ole Troan het = volgende geschreven: >>=20 >> Right, I'm not arguing that we don't need a routing protocol. I'm = not even particularly arguing that PD is the right way to delegate = prefixes. But it would work, and with no protocol changes=97it would = just require an operations document to explain how to do it. >=20 > I see you are making that assertion. I don't believe you. > please write a draft how this would work. >=20 http://tools.ietf.org/html/draft-boot-homenet-brdp-00 Older =84autoconf=94 version was implemented in opnet, the protocol = itself worked, routers (and hosts) were aware of Border Routers (the CPE = boxes with DHCP PD server) and exit links to ISPs with corresponding = prefixes. The autoconfig part was not implemented. It was tailored for = MANET / Autoconf space, not for more static Homenets. Now I work on multi smart-gateway for IPv4 (hmm), build on top of olsrd = (v1). It uses tunnels (instead of SADR). Tunnel management, exit link = detection and route policy management is in separate daemon. We learned = before we should not overload the routing daemon. Multi smart-gateway is prepared for IPv6. Future work is port_on_top_of = or line_up_with OLSRv2 (RFC to be) and adding full IPv6 support based on = SADR, not on tunnels. Using same mechanism in MANET as in Homenet has = our preference. I cannot see much difference. Teco From alexandru.petrescu@gmail.com Wed Feb 5 10:54:51 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6412B1A0138 for ; Wed, 5 Feb 2014 10:54:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2TFEItetguKo for ; Wed, 5 Feb 2014 10:54:48 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id F3EF51A01BC for ; Wed, 5 Feb 2014 10:54:45 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s15IsFIb018391; Wed, 5 Feb 2014 19:54:15 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 670D1203278; Wed, 5 Feb 2014 19:54:36 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 5080C203207; Wed, 5 Feb 2014 19:54:36 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s15IsBcj001851; Wed, 5 Feb 2014 19:54:15 +0100 Message-ID: <52F288D2.9050703@gmail.com> Date: Wed, 05 Feb 2014 19:54:10 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Ole Troan , Ted Lemon References: <52EA442D.3020707@gmail.com> <52EA47AA.90302@gmail.com> <1FE00515-A7AD-4C48-A7F2-63BA8696D818@darou.fr> <52EA4BB1.9010607@gmail.com> <2922CC94-540D-4215-899B-4722BD1C5EBC@employees.org> <52EF90BD.4070701@gmail.com> <18C8BE29C547CC4DBBCF3C4F0B8EC1780608ED@wds-exc1.okna.nominet.org.uk> <8B52F0C3-EB5A-48D1-9596-52302F6A4A3C@darou.fr> <8FA52BBD-9A61-4795-9BA3-AB8B0A63EB98@fugue.com> <29DCB6B2-B428-4B45-8796-ACB09E40376A@fugue.com> <8FB38433-5358-4172-968C-76564A875520@employees.org> <86B24348-2 1AE-43A8-BF16-555EB566BE72@employees.org> <1A7874B2-90B5-4C02-9AAE-510B5CC4E98B@fugue.com> <73E60BBE-35C3-41D3-81AF-139A99C3D5DF@employees.org> In-Reply-To: <73E60BBE-35C3-41D3-81AF-139A99C3D5DF@employees.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: Ray Bellis , "homenet@ietf.org Group" , Markus Stenberg , Pierre Pfister , Lorenzo Colitti Subject: Re: [homenet] DHCP PD X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 18:54:51 -0000 Le 05/02/2014 15:01, Ole Troan a écrit : > Ted, > >>> please take a look at those drafts, and let us know what we've >>> missed in the DHCP PD "solution space". >> >> I've read all those drafts at one time or another. I just >> checked the latest version of >> http://tools.ietf.org/html/draft-gmann-homenet-relay-autoconf and >> it appears to do pretty much the right thing. >> >> One thing that isn't mentioned in that draft that I don't think is >> intuitive to all readers is that if you have two CERs, this >> technique still works; the only difference is that the technique >> has to be done independently by each internal router with respect >> to each CER. > > you make it sound like that's a part and parcel of DHCP. I can't see > how you can implement that today. are there any implementations doing > this? I have never seen any. as an example of the problems you'll > encounter. how does the RR detect the difference between a backup DR > and a separate DR? first case it should pick the best server, second > case it should set up sessions to both. Ole, I think the RR would not need to detect a full difference, but maybe to obtain prefixes from both, and subsequently distinguish between them maybe based on some preference values. If I am not wrong the same scheme of preferences based on lifetime as ND uses, is also used in PD (valid lifetime and preferred lifetime). I guess the RR could also indicate some preference value when requesting prefixes. It would then come down to a more intelligent decision making at the RR. Obtaining two prefixes from two different servers is not that huge of a problem, I think. >> This draft also does not appear to talk about how to get rid of >> prefixes to CERs that have failed. Ideally the homenet routing >> protocol server could signal the DHCPv6 PD requesting router >> server when a CER has gone away, or else the PD requesting router >> server could poll for that information from time to time (you want >> a little hysteresis to avoid needlessly dropping prefixes in the >> event of a router reboot, of course). > > "homenet routing protocol server"? this proposal makes do with > static routing. > > given an arbitrary topology. how do you build the relay topology and > discover DHCP servers? I think it is good to question how would Relays discover servers. But that does not mean that OSPF-or-other-routing-protocol doesn't need same thing. Where one questions the use of multicast - OSPF also relies on it. > use site-local multicast -> we don’t quite know how to bootstrap > that? OSPF also relies on same multicast paradigm. If we know how to do it for OSPF then we'd know for DHCP as well. > hop-by-hop relaying? ? > how do you deal with loops? Loops in a small setting like a homenet may be primarily a matter of where does the default route point to. In the immediate, one wants to make sure these default routes don't lead to loops. This is a reason why one may question how is the default route delivered. A routing protocol which maintains routes will indeed detect loops, but will do little in itself to inform a Host that what it believes to be a default route should not be used. A routing protocol needs to rather inform a Router to modify its radvd.conf towards that Host. That isn't implemented either in widespread implementations, as far as I know. Or, one wouldn't want a routing protocol to replace RA for the default route, right? > you're essentially building a spanning tree of relays. how do you > deal with multiple routers on the link? just keep adding /64s out of > the same site-prefix to it? > > how does the network react to network events? given you rely on DHCP > snooping then network convergence time is rather glacial. > > while DHCP PD may look like a candidate at first glance, to make it > work in all corner cases, you essentially build something quite > different than current DHCP. then you might as well use a real > routing protocol and a prefix assignment protocol designed for the > purpose. Hm. Alex > > cheers, Ole > From brian.e.carpenter@gmail.com Wed Feb 5 11:15:30 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E4981A0140 for ; Wed, 5 Feb 2014 11:15:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oThqaZEZuFOY for ; Wed, 5 Feb 2014 11:15:28 -0800 (PST) Received: from mail-pb0-x234.google.com (mail-pb0-x234.google.com [IPv6:2607:f8b0:400e:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 6798A1A00EB for ; Wed, 5 Feb 2014 11:15:28 -0800 (PST) Received: by mail-pb0-f52.google.com with SMTP id jt11so757196pbb.25 for ; Wed, 05 Feb 2014 11:15:27 -0800 (PST) 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=a8xrWBH8zddDcndrYflle+sixaeP9v4XiTpEPSBDMTk=; b=icD/TSuQbBgB4qMa8GXOdC8V/7cerHRaNpAxqIVP3097zUzHsfV6Yq9uR3OAnJA+78 KvTTsMn1jS6iMzPSsVO1tUaW4OJcRwsg3Si0HmF5OY+9JvlqoiQdLF47ntGdFtNlJX4w zF33hJH8BdSIU9vcxajNpaqGpRluz1VXCt+3H4a3z3AkO9RJfYZG/Sr9fsBiVZslHmLm PFqgYwgOc7c3GudjLvh47BYrrbnK8QOQNhjEdIa92tjDSdQWPEagRL/l4/POh28I4KK1 tvVHFOLYl1oCimUvK9u9ASjEq8Exl+ywplxFMqsWMezotWb7rV1K+YH1U+6nmitrxPQY 7yRA== X-Received: by 10.68.180.66 with SMTP id dm2mr4321376pbc.143.1391627727733; Wed, 05 Feb 2014 11:15:27 -0800 (PST) Received: from [192.168.178.23] (80.199.69.111.dynamic.snap.net.nz. [111.69.199.80]) by mx.google.com with ESMTPSA id j3sm79199378pbh.38.2014.02.05.11.15.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Feb 2014 11:15:27 -0800 (PST) Message-ID: <52F28DD4.8000104@gmail.com> Date: Thu, 06 Feb 2014 08:15:32 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Alexandru Petrescu References: <52EA3361.1010501@gmail.com> <2EB6289E-C7FD-481F-99F9-E35730245943@employees.org> <52EA442D.3020707@gmail.com> <52EA47AA.90302@gmail.com> <1FE00515-A7AD-4C48-A7F2-63BA8696D818@darou.fr> <52EA4BB1.9010607@gmail.com> <2922CC94-540D-4215-899B-4722BD1C5EBC@employees.org> <52EF90BD.4070701@gmail.com> <18C8BE29C547CC4DBBCF3C4F0B8EC1780608ED@wds-exc1.okna.nominet.org.uk> <8B52F0C3-EB5A-48D1-9596-52302F6A4A3C@darou.fr> <8FA52BBD-9A61-4795-9BA3-AB8B0A63EB98@fugue.com> <29DCB6B2-B428-4B45-8796-ACB09E40376A@fugue.com> <26945.1391525921@sandelman.ca> <2BE96E0A-D9A7-492F-B07F-9C83767C6F0D@darou.fr> <445.1391555635@sandelman.ca> <52F1A6D6.8020801@gmail.com> <52F22AF1.6060300@gmail.com> In-Reply-To: <52F22AF1.6060300@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: homenet@ietf.org Subject: [homenet] Prefix semantics (not) [was: DHCP PD] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 19:15:30 -0000 On 06/02/2014 01:13, Alexandru Petrescu wrote: > Le 05/02/2014 09:06, Mikael Abrahamsson a =C3=A9crit : >> On Wed, 5 Feb 2014, Brian E Carpenter wrote: >> >>> On 05/02/2014 12:13, Michael Richardson wrote: >>>> Pierre Pfister wrote: >>> ... >>>>> For instance, if a prefix is for general purpose, and another is fo= r >>>>> voice >>>>> applications, then hosts may only get addresses for voice >>>>> application, and >>>>> would therefore not being able to access the internet. >>> >>> Yes, that's one of many reasons why using prefixes to distinguish >>> types of traffic is a really bad idea. >> >> The idea is that "non color-aware" devices will only use the "Internet= " >> prefix, by means of the colored prefixes will use a different ND PIO >> type for prefix announcement (thus invisible to these non color-aware >> hosts), plus DHCPv6 server would only hand out prefixes/addresses to >> hosts that request them. >=20 > A color could also be a particular value for the flow label field. No, a DSCP. The flow label value is supposed to be opaque with no semantics. We designed diffserv for this purpose and it works well and is quite widely used in corporate networks. Wasting prefixes to distinguish traffic types is an incredibly bad idea. brian From swmike@swm.pp.se Wed Feb 5 23:46:18 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DFF21A038F for ; Wed, 5 Feb 2014 23:46:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.386 X-Spam-Level: X-Spam-Status: No, score=-4.386 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SdLiqMUs2tnO for ; Wed, 5 Feb 2014 23:46:16 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by ietfa.amsl.com (Postfix) with ESMTP id 6A86B1A0389 for ; Wed, 5 Feb 2014 23:46:16 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id B124E9C; Thu, 6 Feb 2014 08:46:14 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id A13D89A; Thu, 6 Feb 2014 08:46:14 +0100 (CET) Date: Thu, 6 Feb 2014 08:46:14 +0100 (CET) From: Mikael Abrahamsson To: Brian E Carpenter In-Reply-To: <52F28DD4.8000104@gmail.com> Message-ID: References: <52EA442D.3020707@gmail.com> <52EA47AA.90302@gmail.com> <1FE00515-A7AD-4C48-A7F2-63BA8696D818@darou.fr> <52EA4BB1.9010607@gmail.com> <2922CC94-540D-4215-899B-4722BD1C5EBC@employees.org> <52EF90BD.4070701@gmail.com> <18C8BE29C547CC4DBBCF3C4F0B8EC1780608ED@wds-exc1.okna.nominet.org.uk> <8B52F0C3-EB5A-48D1-9596-52302F6A4A3C@darou.fr> <8FA52BBD-9A61-4795-9BA3-AB8B0A63EB98@fugue.com> <29DCB6B2-B428-4B45-8796-ACB09E40376A@fugue.com> <26945.1391525921@sandelman.ca> <2BE96E0A-D9A7-492F-B07F-9C83767C6F0D@darou.fr> <445.1391555635@sandelman.ca> <52F1A6D6.8020801@gmail.com> <52F22AF1.6060300@gmail.com> <52F28DD4.8000104@gmail.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: homenet@ietf.org Subject: Re: [homenet] Prefix semantics (not) [was: DHCP PD] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 07:46:18 -0000 On Thu, 6 Feb 2014, Brian E Carpenter wrote: > We designed diffserv for this purpose and it works well and is quite > widely used in corporate networks. Wasting prefixes to distinguish > traffic types is an incredibly bad idea. Problem with DSCP is that you have to reset them for a non-qos service in your network (unless you're running some kind of encapsulation scheme such as tunnels or MPLS). -- Mikael Abrahamsson email: swmike@swm.pp.se From pierre.pfister@darou.fr Thu Feb 6 08:16:23 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C27171A03C5 for ; Thu, 6 Feb 2014 08:16:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.882 X-Spam-Level: X-Spam-Status: No, score=-1.882 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N8Zd5fXfxDWw for ; Thu, 6 Feb 2014 08:16:21 -0800 (PST) Received: from ks395963.kimsufi.com (darou.fr [176.31.121.140]) by ietfa.amsl.com (Postfix) with ESMTP id 8A89C1A01FA for ; Thu, 6 Feb 2014 08:16:21 -0800 (PST) Received: from [172.29.115.221] (unknown [198.202.203.177]) (Authenticated sender: pierre@darou.fr) by ks395963.kimsufi.com (Postfix) with ESMTPSA id 4CE6060346; Thu, 6 Feb 2014 17:16:17 +0100 (CET) From: Pierre Pfister Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Feb 2014 09:16:16 -0700 Message-Id: To: "homenet@ietf.org Group" Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) X-Mailer: Apple Mail (2.1827) Cc: benjamin@paterson.fr, Jari Arkko Subject: [homenet] New draft - Prefix and Address Assignment in a Home Network X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 16:16:24 -0000 Hello, We just published a new draft concerning prefix and address assignment = in home networks. http://tools.ietf.org/html/draft-pfister-homenet-prefix-assignment-00 It is a continuation of arkko=92s prefix assignment draft = (draft-arkko-homenet-prefix-assignment-04). It provides new features and = may run on top of any information propagation protocol that fulfills the = specified requirements. Your comments are very welcome. Pierre= From brian.e.carpenter@gmail.com Thu Feb 6 11:39:14 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 673C91A0461 for ; Thu, 6 Feb 2014 11:39:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l9k-tMWHYYc9 for ; Thu, 6 Feb 2014 11:39:12 -0800 (PST) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id CFC5F1A0478 for ; Thu, 6 Feb 2014 11:39:12 -0800 (PST) Received: by mail-pa0-f49.google.com with SMTP id hz1so2107350pad.22 for ; Thu, 06 Feb 2014 11:39:11 -0800 (PST) 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=jg86lW06kvNfr9dUXRsxXIZS4sHf0nPNbJoxlx35Zn4=; b=PmPkjVj3H0x5BGelhTYeEl6fGIwk5ar7Td2QI7OS9x8kLn8mmdlOO8ijQvfedHWEYy NFet2adr/XMtzJVUqP/4sh2F9fX6N3Z277eunmkgzIR4RaUTfUfRrUfuu+ijnei3i0Wv ykCqRhydT4tjtCESdbOT6amPhgKdNF89A1PFRMNr0naCH14y8VsEWKzcf2q1JBTKlPaV 47Jgj405xR9tT5o29ZI8+ZHaQVB3vOXJqTl3C0Rs1csJPoUz2D0+JAB6pto6ngguKwqu 1L1A99jtNotZKo9bEJZq2wzZVuxfrUpFn5GtYMPA3No7lE4X3voMDNPULS5/xG74Emq3 gjEA== X-Received: by 10.68.143.100 with SMTP id sd4mr14665844pbb.0.1391715544228; Thu, 06 Feb 2014 11:39:04 -0800 (PST) Received: from [192.168.178.23] (33.195.69.111.dynamic.snap.net.nz. [111.69.195.33]) by mx.google.com with ESMTPSA id om6sm6094317pbc.43.2014.02.06.11.39.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Feb 2014 11:39:03 -0800 (PST) Message-ID: <52F3E4DF.5070302@gmail.com> Date: Fri, 07 Feb 2014 08:39:11 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mikael Abrahamsson References: <52EA442D.3020707@gmail.com> <52EA47AA.90302@gmail.com> <1FE00515-A7AD-4C48-A7F2-63BA8696D818@darou.fr> <52EA4BB1.9010607@gmail.com> <2922CC94-540D-4215-899B-4722BD1C5EBC@employees.org> <52EF90BD.4070701@gmail.com> <18C8BE29C547CC4DBBCF3C4F0B8EC1780608ED@wds-exc1.okna.nominet.org.uk> <8B52F0C3-EB5A-48D1-9596-52302F6A4A3C@darou.fr> <8FA52BBD-9A61-4795-9BA3-AB8B0A63EB98@fugue.com> <29DCB6B2-B428-4B45-8796-ACB09E40376A@fugue.com> <26945.1391525921@sandelman.ca> <2BE96E0A-D9A7-492F-B07F-9C83767C6F0D@darou.fr> <445.1391555635@sandelman.ca> <52F1A6D6.8020801@gmail.com> <52F22AF1.6060300@gmail.com> <52F28DD4.8000104@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org Subject: Re: [homenet] Prefix semantics (not) [was: DHCP PD] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 19:39:14 -0000 On 06/02/2014 20:46, Mikael Abrahamsson wrote: > On Thu, 6 Feb 2014, Brian E Carpenter wrote: > >> We designed diffserv for this purpose and it works well and is quite >> widely used in corporate networks. Wasting prefixes to distinguish >> traffic types is an incredibly bad idea. > > Problem with DSCP is that you have to reset them for a non-qos service > in your network (unless you're running some kind of encapsulation scheme > such as tunnels or MPLS). Sorry, what, why? DSCP is a no-op for a router that doesn't implement diffserv, so why would you ever need to reset them? (It's normal for border routers to clear the DSCP if they want to, of course; no harm, no foul.) Brian From lorenzo@google.com Thu Feb 6 16:54:35 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCEE61A0584 for ; Thu, 6 Feb 2014 16:54:35 -0800 (PST) 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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j9B3ERoTF26o for ; Thu, 6 Feb 2014 16:54:34 -0800 (PST) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id D52341A0585 for ; Thu, 6 Feb 2014 16:54:33 -0800 (PST) Received: by mail-qc0-f169.google.com with SMTP id w7so4734133qcr.28 for ; Thu, 06 Feb 2014 16:54:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=nk43ha+bNfAew58Pi5l4tLeUgToghBuWWmh6l/aMPeU=; b=mOWCt1EAIth05MJ0sgvrbjuk23tQGATCln8GlLGrUtgVQsVOdhtkNVVbAOIPmJUGBq neP42EKFVuoyHNY4yBACyJ16ZtjNqMlmxx/AhNO8mtJHo4H+jZ6q/RUI3M2o78hBC8I2 GPeXvhklrQzKnqYHkpgAekygholexlBGRm6id0eFA0Bodn6c03CV8xuwUf+eUXPx+gLM kr5ZcEcJHw1ZMB7g9p0uNZKBKaulaP42DssWMCdFR4a2KffB509/W/lbCLVSpyyUROpG tQawmaDlpnrncX6YbmCVw64xVmW2QjSMSdWMXw8ZLw8s2OSf6Uufnx2Q9kx4qiOHKnO/ cjew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=nk43ha+bNfAew58Pi5l4tLeUgToghBuWWmh6l/aMPeU=; b=OBEzuepFLmrriHaRbEvhRHoQCnwbKcp743Nzz86zUe7YW9KXbPkxAB/fFUATW11B9W wQGAl/yLRI6y2hJ3kz/DYndRXiChXVp4jEZDamM5tK8gUdo/0ERM1kdzHM9dwPIuxWOj WgRyVJKPO+xD8jS7sH5ZqT8lMA/2gtP5NZPuqD9suOyapH1CXA40xbRWrrBK98his3h+ ZTE6zAmyglNg2bqnaSV8u3tgHn2fmy790AHv5FtLSPYfHs+5Z4vo8RBSvyQ8RGAQSB1f JSvlCjRCfnIRlfsrMLbmiYtMtzNqMbmt9c6mMnjU2oGqiMyzCQ/OfTVvGMgEGpFiPk6B QP7g== X-Gm-Message-State: ALoCoQk2sUIVi5/zgbFgMJWofmmX2eoBIMr7MERJqZvAse5E/5jcmEAGpk2pZIkgYX5hKx1oUaNSXag/Q4+cG50ne0B7jE8+DZ9ci4UdlmgdW1gy01nQgnEZ7kSoRaYdpWzwZLxuIkz11SX5KWgbtnpxtSDZxwCEEg0w9VmVvIJukNZAtU4r7P80SADcb5po2YdA5tByo/ir X-Received: by 10.224.121.137 with SMTP id h9mr17075813qar.55.1391734472430; Thu, 06 Feb 2014 16:54:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.234.193 with HTTP; Thu, 6 Feb 2014 16:54:12 -0800 (PST) In-Reply-To: References: <52EA442D.3020707@gmail.com> <52EA47AA.90302@gmail.com> <1FE00515-A7AD-4C48-A7F2-63BA8696D818@darou.fr> <52EA4BB1.9010607@gmail.com> <2922CC94-540D-4215-899B-4722BD1C5EBC@employees.org> <52EF90BD.4070701@gmail.com> <18C8BE29C547CC4DBBCF3C4F0B8EC1780608ED@wds-exc1.okna.nominet.org.uk> <8B52F0C3-EB5A-48D1-9596-52302F6A4A3C@darou.fr> <8FA52BBD-9A61-4795-9BA3-AB8B0A63EB98@fugue.com> <29DCB6B2-B428-4B45-8796-ACB09E40376A@fugue.com> <26945.1391525921@sandelman.ca> <2BE96E0A-D9A7-492F-B07F-9C83767C6F0D@darou.fr> <445.1391555635@sandelman.ca> <52F1A6D6.8020801@gmail.com> <52F22AF1.6060300@gmail.com> <52F28DD4.8000104@gmail.com> From: Lorenzo Colitti Date: Thu, 6 Feb 2014 16:54:12 -0800 Message-ID: To: Mikael Abrahamsson Content-Type: multipart/alternative; boundary=089e0160c242da263f04f1c66eb3 Cc: "homenet@ietf.org" Subject: Re: [homenet] Prefix semantics (not) [was: DHCP PD] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 00:54:35 -0000 --089e0160c242da263f04f1c66eb3 Content-Type: text/plain; charset=UTF-8 On Wed, Feb 5, 2014 at 11:46 PM, Mikael Abrahamsson wrote: > We designed diffserv for this purpose and it works well and is quite >> widely used in corporate networks. Wasting prefixes to distinguish traffic >> types is an incredibly bad idea. >> > > Problem with DSCP is that you have to reset them for a non-qos service in > your network (unless you're running some kind of encapsulation scheme such > as tunnels or MPLS). This is no different from what you need to do with prefixes, due to BCP 38. DSCP: When a packet comes in, you check DSCP, and possibly rewrite it. Prefix: When a packet comes in, you check the source / dst prefix, check DSCP, possibly drop the packet, and possibly rewrite DSCP. --089e0160c242da263f04f1c66eb3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Feb 5, 2014 at 11:46 PM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
We designed diffserv for this purpose and it works well and is quite widely= used in corporate networks. Wasting prefixes to distinguish traffic types = is an incredibly bad idea.

Problem with DSCP is that you have to reset them for a non-qos service in y= our network (unless you're running some kind of encapsulation scheme su= ch as tunnels or MPLS).

This is no differen= t from what you need to do with prefixes, due to BCP 38.

DSCP: When a packet comes in, you check DSCP, and possi= bly rewrite it.
Prefix: When a packet comes in, you check th= e source / dst prefix, check DSCP, possibly drop the packet, and possibly r= ewrite DSCP.
--089e0160c242da263f04f1c66eb3-- From swmike@swm.pp.se Thu Feb 6 19:10:19 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8A311A04B6 for ; Thu, 6 Feb 2014 19:10:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yLcyHZz1gcQb for ; Thu, 6 Feb 2014 19:10:18 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id DCF831A0348 for ; Thu, 6 Feb 2014 19:10:17 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 010609C; Fri, 7 Feb 2014 04:10:14 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id EC8A29A; Fri, 7 Feb 2014 04:10:14 +0100 (CET) Date: Fri, 7 Feb 2014 04:10:14 +0100 (CET) From: Mikael Abrahamsson To: Brian E Carpenter In-Reply-To: <52F3E4DF.5070302@gmail.com> Message-ID: References: <52EA47AA.90302@gmail.com> <1FE00515-A7AD-4C48-A7F2-63BA8696D818@darou.fr> <52EA4BB1.9010607@gmail.com> <2922CC94-540D-4215-899B-4722BD1C5EBC@employees.org> <52EF90BD.4070701@gmail.com> <18C8BE29C547CC4DBBCF3C4F0B8EC1780608ED@wds-exc1.okna.nominet.org.uk> <8B52F0C3-EB5A-48D1-9596-52302F6A4A3C@darou.fr> <8FA52BBD-9A61-4795-9BA3-AB8B0A63EB98@fugue.com> <29DCB6B2-B428-4B45-8796-ACB09E40376A@fugue.com> <26945.1391525921@sandelman.ca> <2BE96E0A-D9A7-492F-B07F-9C83767C6F0D@darou.fr> <445.1391555635@sandelman.ca> <52F1A6D6.8020801@gmail.com> <52F22AF1.6060300@gmail.com> <52F28DD4.8000104@gmail.com> <52F3E4DF.5070302@gmail.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: homenet@ietf.org Subject: Re: [homenet] Prefix semantics (not) [was: DHCP PD] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 03:10:20 -0000 On Fri, 7 Feb 2014, Brian E Carpenter wrote: > Sorry, what, why? DSCP is a no-op for a router that doesn't implement > diffserv, so why would you ever need to reset them? (It's normal for > border routers to clear the DSCP if they want to, of course; no harm, no > foul.) If my core understands DSCP and acts on it, I don't want non-QoS customers to send EF traffic, overloading my priority queue with their DDOS traffic. -- Mikael Abrahamsson email: swmike@swm.pp.se From brian.e.carpenter@gmail.com Thu Feb 6 20:35:15 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA5B61A0346 for ; Thu, 6 Feb 2014 20:35:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AXRNHoG0kSKA for ; Thu, 6 Feb 2014 20:35:14 -0800 (PST) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 4E8431A0294 for ; Thu, 6 Feb 2014 20:35:14 -0800 (PST) Received: by mail-pa0-f47.google.com with SMTP id kp14so2667280pab.20 for ; Thu, 06 Feb 2014 20:35:13 -0800 (PST) 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=L6GAKNZV+bg0P/vn7dxSukipM3RMOOscIbg4IVUG7QY=; b=pLQu08gCnP31pjHOXEVhVi8UwzOUvfyNeFz2dgH//TFRgnsZOR8C2eq5LV+RcusxC7 6ad2QHMC0xR0CBOR5hYkktHaOdwqb/Xa3LAyEtZ/OYgkx4j1UCt5SVvnq8swNC+8twHc I0hnI97XrW9NIymiJ6+ewQe1Sigjrpg+cOlZjeECBqL6MJ0XHP0Ewp32h6J/ROPfPdri wHyDe9+6OWkUVEM0hPGEAetPIljEDRixXbgbHDM6ZNFwi3KMwzrnqkGuZbSRjyXJkS7H r1neE57bMneLNqKZzb4Y06Wm7n9OMFHJY6UzN/pb67N0Xgdg49M9JuQaBwoUmJEE8r5L VO7w== X-Received: by 10.68.0.99 with SMTP id 3mr17075351pbd.68.1391747713148; Thu, 06 Feb 2014 20:35:13 -0800 (PST) Received: from [192.168.178.23] (33.195.69.111.dynamic.snap.net.nz. [111.69.195.33]) by mx.google.com with ESMTPSA id js7sm8977239pbc.35.2014.02.06.20.35.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Feb 2014 20:35:12 -0800 (PST) Message-ID: <52F46288.10402@gmail.com> Date: Fri, 07 Feb 2014 17:35:20 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mikael Abrahamsson References: <52EA47AA.90302@gmail.com> <1FE00515-A7AD-4C48-A7F2-63BA8696D818@darou.fr> <52EA4BB1.9010607@gmail.com> <2922CC94-540D-4215-899B-4722BD1C5EBC@employees.org> <52EF90BD.4070701@gmail.com> <18C8BE29C547CC4DBBCF3C4F0B8EC1780608ED@wds-exc1.okna.nominet.org.uk> <8B52F0C3-EB5A-48D1-9596-52302F6A4A3C@darou.fr> <8FA52BBD-9A61-4795-9BA3-AB8B0A63EB98@fugue.com> <29DCB6B2-B428-4B45-8796-ACB09E40376A@fugue.com> <26945.1391525921@sandelman.ca> <2BE96E0A-D9A7-492F-B07F-9C83767C6F0D@darou.fr> <445.1391555635@sandelman.ca> <52F1A6D6.8020801@gmail.com> <52F22AF1.6060300@gmail.com> <52F28DD4.8000104@gmail.com> <52F3E4DF.5070302@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org Subject: Re: [homenet] Prefix semantics (not) [was: DHCP PD] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 04:35:15 -0000 On 07/02/2014 16:10, Mikael Abrahamsson wrote: > On Fri, 7 Feb 2014, Brian E Carpenter wrote: > >> Sorry, what, why? DSCP is a no-op for a router that doesn't implement >> diffserv, so why would you ever need to reset them? (It's normal for >> border routers to clear the DSCP if they want to, of course; no harm, >> no foul.) > > If my core understands DSCP and acts on it, I don't want non-QoS > customers to send EF traffic, overloading my priority queue with their > DDOS traffic. Of course; that's Diffserv 101. If you don't have a Diffserv SLA with a customer, I'd expect you to clear the DSCP, or if you were feeling charitable, run the traffic through a diffserv classifier. I don't see any single respect in which homenets are different, and I don't see that a device asserting "I am a telephone, not a DOS vector" is helped by it using a special prefix. Source addresses can be forged just as easily as DSCPs. Brian From teco@inf-net.nl Thu Feb 6 22:46:54 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 327521A05B0 for ; Thu, 6 Feb 2014 22:46:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KFTrCKdmFZrT for ; Thu, 6 Feb 2014 22:46:52 -0800 (PST) Received: from mail-ea0-f170.google.com (mail-ea0-f170.google.com [209.85.215.170]) by ietfa.amsl.com (Postfix) with ESMTP id 2A31E1A05AE for ; Thu, 6 Feb 2014 22:46:51 -0800 (PST) Received: by mail-ea0-f170.google.com with SMTP id k10so1349103eaj.1 for ; Thu, 06 Feb 2014 22:46:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=7GzoyFgLI6tSQoqEKWk/U14VC7RnPDZaK8fLjQYKckU=; b=dmZ5mQtTHWmDcvwGbp3v8qeUFmPHe8IersZTYEIcRcogjGhHVAwG8SX0Wkgb8SPA4G bKQ6TNluHJYFBOL3TKLI0GTw63ZUpaImtDVf0Qlf089R0EmWWPIzp1+akrdIlwI1Z3Zo fy4/lDg2qglsGVPkzlPIeg2iKtgPtaii4IedDmQOA0fQiSUxRkFSkFd8Q1npUelDGGir rWcQtn1Ghs1My1uwUNUK8IB9S2VwEEIzNwpfsb9oOl3FsHROP7zm/zcdd0v52rYEdB+S KsMxIANBAZUyenWB0IJa11b0exnJAjg/uweTwFHFpj0R+UQJReXPXDRZJyM4DAawXR2K jeAA== X-Gm-Message-State: ALoCoQkJS21rXYNeBC+VEVOWQPF2uPauzAsIf4OTe2sRWXuoFwXGv/fHNJ/Pp838HbcPEXuZpjIv X-Received: by 10.14.172.133 with SMTP id t5mr648622eel.99.1391755609650; Thu, 06 Feb 2014 22:46:49 -0800 (PST) Received: from [10.175.173.95] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPSA id d9sm12614332eei.9.2014.02.06.22.46.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Feb 2014 22:46:47 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Teco Boot In-Reply-To: <52F3E4DF.5070302@gmail.com> Date: Fri, 7 Feb 2014 07:50:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52EA442D.3020707@gmail.com> <52EA47AA.90302@gmail.com> <1FE00515-A7AD-4C48-A7F2-63BA8696D818@darou.fr> <52EA4BB1.9010607@gmail.com> <2922CC94-540D-4215-899B-4722BD1C5EBC@employees.org> <52EF90BD.4070701@gmail.com> <18C8BE29C547CC4DBBCF3C4F0B8EC1780608ED@wds-exc1.okna.nominet.org.uk> <8B52F0C3-EB5A-48D1-9596-52302F6A4A3C@darou.fr> <8FA52BBD-9A61-4795-9BA3-AB8B0A63EB98@fugue.com> <29DCB6B2-B428-4B45-8796-ACB09E40376A@fugue.com> <26945.1391525921@sandelman.ca> <2BE96E0A-D9A7-492F-B07F-9C83767C6F0D@darou.fr> <445.1391555635@sandelman.ca> <52F1A6D6.8020801@gmail.com> <52F22AF1.6060300@gmail.com> <52F28DD4.8000104@gmail.com> <52F3E4DF.5070302@gmail.c om> To: Brian E Carpenter X-Mailer: Apple Mail (2.1827) Cc: "homenet@ietf.org Group" , Mikael Abrahamsson Subject: Re: [homenet] Prefix semantics (not) [was: DHCP PD] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 06:46:54 -0000 Op 6 feb. 2014, om 20:39 heeft Brian E Carpenter = het volgende geschreven: > On 06/02/2014 20:46, Mikael Abrahamsson wrote: >> On Thu, 6 Feb 2014, Brian E Carpenter wrote: >>=20 >>> We designed diffserv for this purpose and it works well and is quite >>> widely used in corporate networks. Wasting prefixes to distinguish >>> traffic types is an incredibly bad idea. >>=20 >> Problem with DSCP is that you have to reset them for a non-qos = service >> in your network (unless you're running some kind of encapsulation = scheme >> such as tunnels or MPLS). >=20 > Sorry, what, why? DSCP is a no-op for a router that doesn't > implement diffserv, so why would you ever need to reset them? > (It's normal for border routers to clear the DSCP if they want to, > of course; no harm, no foul.) No harm? Hmm. Two edge networks are connected via backbone and try to = use end to end QoS. It is not unusual to add a tunnel, just to protect = against DSCP rewrites. Teco From joelja@bogus.com Thu Feb 6 23:20:59 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD341A05BE for ; Thu, 6 Feb 2014 23:20:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lOaE-xObIGq8 for ; Thu, 6 Feb 2014 23:20:57 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 748FF1A05BC for ; Thu, 6 Feb 2014 23:20:57 -0800 (PST) Received: from mb-aye.local (c-50-174-18-221.hsd1.ca.comcast.net [50.174.18.221]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s177KrAj042719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 7 Feb 2014 07:20:54 GMT (envelope-from joelja@bogus.com) Message-ID: <52F4894F.9000205@bogus.com> Date: Thu, 06 Feb 2014 23:20:47 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:27.0) Gecko/20100101 Thunderbird/27.0 MIME-Version: 1.0 To: Teco Boot , Brian E Carpenter References: <52EA47AA.90302@gmail.com> <1FE00515-A7AD-4C48-A7F2-63BA8696D818@darou.fr> <52EA4BB1.9010607@gmail.com> <2922CC94-540D-4215-899B-4722BD1C5EBC@employees.org> <52EF90BD.4070701@gmail.com> <18C8BE29C547CC4DBBCF3C4F0B8EC1780608ED@wds-exc1.okna.nominet.org.uk> <8B52F0C3-EB5A-48D1-9596-52302F6A4A3C@darou.fr> <8FA52BBD-9A61-4795-9BA3-AB8B0A63EB98@fugue.com> <29DCB6B2-B428-4B45-8796-ACB09E40376A@fugue.com> <26945.1391525921@sandelman.ca> <2BE96E0A-D9A7-492F-B07F-9C83767C6F0D@darou.fr> <445.1391555635@sandelman.ca> <52F1A6D6.8020801@gmail.com> <52F22AF1.6060300@gmail.com> <52F28DD4.8000104@gmail.com> <52F3E4DF.5070302@gmail.c om> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="l266wK2M37fDgADdLs126jcuDsLuDp0hM" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Fri, 07 Feb 2014 07:20:55 +0000 (UTC) Cc: "homenet@ietf.org Group" , Mikael Abrahamsson Subject: Re: [homenet] Prefix semantics (not) [was: DHCP PD] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 07:20:59 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --l266wK2M37fDgADdLs126jcuDsLuDp0hM Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2/6/14, 10:50 PM, Teco Boot wrote: >=20 > Op 6 feb. 2014, om 20:39 heeft Brian E Carpenter het volgende geschreven: >=20 >> On 06/02/2014 20:46, Mikael Abrahamsson wrote: >>> On Thu, 6 Feb 2014, Brian E Carpenter wrote: >>> >>>> We designed diffserv for this purpose and it works well and is quite= >>>> widely used in corporate networks. Wasting prefixes to distinguish >>>> traffic types is an incredibly bad idea. >>> >>> Problem with DSCP is that you have to reset them for a non-qos servic= e >>> in your network (unless you're running some kind of encapsulation sch= eme >>> such as tunnels or MPLS). >> >> Sorry, what, why? DSCP is a no-op for a router that doesn't >> implement diffserv, so why would you ever need to reset them? >> (It's normal for border routers to clear the DSCP if they want to, >> of course; no harm, no foul.) >=20 > No harm? Hmm. Two edge networks are connected via backbone and try to u= se end to end QoS. It is not unusual to add a tunnel, just to protect aga= inst DSCP rewrites. if you include the DSCP in your hash algorithm really funny things happen when providers that set them differently on different parts of the same flows (e.g. prioritizing syn/ack) fail to sanitize them at their border. there's a lot of pollution in DSCP which means you really should sanitize them before you employ those bits. > Teco >=20 >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet >=20 --l266wK2M37fDgADdLs126jcuDsLuDp0hM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlL0iVAACgkQ8AA1q7Z/VrJSBgCfbPntNZ+JnL0So2gTubl4FfNm 7F4AnA3m3TOx7OLLWX4vQDHaYkuL3Sbv =tdcl -----END PGP SIGNATURE----- --l266wK2M37fDgADdLs126jcuDsLuDp0hM-- From mark@townsley.net Fri Feb 7 02:26:13 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21F5C1A05F6 for ; Fri, 7 Feb 2014 02:26:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xqkQzqxXiVF5 for ; Fri, 7 Feb 2014 02:26:09 -0800 (PST) Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) by ietfa.amsl.com (Postfix) with ESMTP id 98C9E1A05F7 for ; Fri, 7 Feb 2014 02:26:09 -0800 (PST) Received: by mail-wi0-f169.google.com with SMTP id e4so666121wiv.4 for ; Fri, 07 Feb 2014 02:26:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=wasZqK5KBCa9id4sPHjHRO5dPHJZGK5ODj2G+Txj/ec=; b=OjYfoq7CTxGrlVo6bAfmSPjC+tw7G92/qTrR4qW90CjmchZAWGRz32e+bov0t5qlnN yQimPp9AWTpcrJz7/N00buzX6EU+y1b8zY8qLjmUuUoiTgDU/pQy1UGv54rJm/N+nbJz jfhn9kECz2VNwIiCwXoUIvw/xKpL2Z+rL8K0KM1445Xn10XVJMWzlvV/KzfnFerPglIG DPGmjNbNyweumKmB20Qkgfd2kHcavD/Nbokf3XDP6bZY3nEJHPdQvAVPyie/1CgNS4cO iQ0QYMXPYv8G6MTLKu7qgLI3CzHyLOPcyLfvzjMBrcnZFYAC+mKXwZugUbybhyWiV7qi m76Q== X-Gm-Message-State: ALoCoQm0JAvy4AKfQoVQMDFr/6lRxnCWEF5ztU+qTz8y/F2gNStDZDjjdO8KNmwlRCHj2k8aX8jz X-Received: by 10.180.211.50 with SMTP id mz18mr3136159wic.43.1391768767766; Fri, 07 Feb 2014 02:26:07 -0800 (PST) Received: from pc14.home (AMontsouris-653-1-24-200.w92-141.abo.wanadoo.fr. [92.141.7.200]) by mx.google.com with ESMTPSA id ju6sm9563390wjc.1.2014.02.07.02.26.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 07 Feb 2014 02:26:06 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Mark Townsley In-Reply-To: <52F28DD4.8000104@gmail.com> Date: Fri, 7 Feb 2014 11:26:06 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <51637E3C-7BA6-4AB2-96C3-1B23C6F15C9D@townsley.net> References: <52EA3361.1010501@gmail.com> <2EB6289E-C7FD-481F-99F9-E35730245943@employees.org> <52EA442D.3020707@gmail.com> <52EA47AA.90302@gmail.com> <1FE00515-A7AD-4C48-A7F2-63BA8696D818@darou.fr> <52EA4BB1.9010607@gmail.com> <2922CC94-540D-4215-899B-4722BD1C5EBC@employees.org> <52EF90BD.4070701@gmail.com> <18C8BE29C547CC4DBBCF3C4F0B8EC1780608ED@wds-exc1.okna.nominet.org.uk> <8B52F0C3-EB5A-48D1-9596-52302F6A4A3C@darou.fr> <8FA52BBD-9A61-4795-9BA3-AB8B0A63EB98@fugue.com> <29DCB6B2-B428-4B45-8796-ACB09E40376A@fugue.com> <26945.1391525921@sandelman.ca> <2BE96E0A-D9A7-492F-B07F-9C83767C6F0D@darou.fr> <445.1391555635@sandelman.ca> <52F1A6D6.8020801@gmail.com> <52F22AF1.6060300@gmail.com> <52F28DD4.8000104@gmail.com > To: Brian E Carpenter X-Mailer: Apple Mail (2.1283) Cc: Alexandru Petrescu , homenet@ietf.org Subject: Re: [homenet] DSCP (was: Prefix semantics (not) [was: DHCP PD]) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 10:26:13 -0000 Brian, As you point out, DSCP does of course work between endpoints within an = enterprise network just as it was designed to do. It's reasonable to = think that the same technology could be used in other environments, but = the track record of it doing so outside of a tightly controlled domain = is rather poor. Reclassifying at boundaries is expensive, often = inaccurate, and ultimately doomed as we encrypt more and more end to = end. It would be great if diffserv worked across the Internet, multicast = would be nice as well. But, heck, we can't even get PMTUD working well = enough to truly depend on.=20 - Mark On Feb 5, 2014, at 8:15 PM, Brian E Carpenter wrote: > On 06/02/2014 01:13, Alexandru Petrescu wrote: >> Le 05/02/2014 09:06, Mikael Abrahamsson a =E9crit : >>> On Wed, 5 Feb 2014, Brian E Carpenter wrote: >>>=20 >>>> On 05/02/2014 12:13, Michael Richardson wrote: >>>>> Pierre Pfister wrote: >>>> ... >>>>>> For instance, if a prefix is for general purpose, and another is = for >>>>>> voice >>>>>> applications, then hosts may only get addresses for voice >>>>>> application, and >>>>>> would therefore not being able to access the internet. >>>>=20 >>>> Yes, that's one of many reasons why using prefixes to distinguish >>>> types of traffic is a really bad idea. >>>=20 >>> The idea is that "non color-aware" devices will only use the = "Internet" >>> prefix, by means of the colored prefixes will use a different ND PIO >>> type for prefix announcement (thus invisible to these non = color-aware >>> hosts), plus DHCPv6 server would only hand out prefixes/addresses to >>> hosts that request them. >>=20 >> A color could also be a particular value for the flow label field. >=20 > No, a DSCP. The flow label value is supposed to be opaque with > no semantics. >=20 > We designed diffserv for this purpose and it works well and is quite > widely used in corporate networks. Wasting prefixes to distinguish > traffic types is an incredibly bad idea. >=20 > brian >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From mark@townsley.net Fri Feb 7 02:31:49 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5939F1A05FD for ; Fri, 7 Feb 2014 02:31:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VHnNs57AZHnC for ; Fri, 7 Feb 2014 02:31:47 -0800 (PST) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6F61A05FB for ; Fri, 7 Feb 2014 02:31:47 -0800 (PST) Received: by mail-wi0-f182.google.com with SMTP id f8so683797wiw.15 for ; Fri, 07 Feb 2014 02:31:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=K84aKZd/oAwvrTBicvMIl/R1kac1czGO9DRVELyfcvc=; b=HAtgaNi3lVPK+DSjJzHX277ZjPeMp0Plalp1GmM+SFbk8I7Iw9sF1TYJVUW5ySf4Z/ fXxFogA4UTIXl4Iq9kb/FVSsTrza5TCEVXjUtt40VAjFGgEk7rhS88lYD254MBpOiRXA lRFyLy4fmVZX4UftrLksDqe5FpDhtlfU7yUV/6+feI2ApuVW2PTnBugBMvQvDPTtNifW cDzKF65dK7n3BXz+7NAI0nmMmg4I7Ri2PO/jc9/310pr+RT5lxmmTUIAEkfDF027ls2j 6iZT1choWNPEBn8XgBrFEAABDO93xHxeXYpCmaqjTcbLJYFp2N8NrXpaQQCLu5KP5sgC C52w== X-Gm-Message-State: ALoCoQkZI4XjlcpTIe8zbrb3H5IbrqZesJXb0NH5AIQ87dwYxmQMP8Qo96YRmoXrjm59LbaG/D7R X-Received: by 10.194.78.16 with SMTP id x16mr199998wjw.86.1391769105698; Fri, 07 Feb 2014 02:31:45 -0800 (PST) Received: from pc14.home (AMontsouris-653-1-24-200.w92-141.abo.wanadoo.fr. [92.141.7.200]) by mx.google.com with ESMTPSA id n15sm6953797wij.3.2014.02.07.02.31.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 07 Feb 2014 02:31:45 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: <32165.1391437144@sandelman.ca> Date: Fri, 7 Feb 2014 11:31:44 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <87iosy2tf4.wl%jch@pps.univ-paris-diderot.fr> <52EDBEDA.1020208@gmail.com> <32165.1391437144@sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1283) Cc: "homenet@ietf.org Group" , Juliusz Chroboczek Subject: Re: [homenet] Homenet protocol decisions X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 10:31:49 -0000 On Feb 3, 2014, at 3:19 PM, Michael Richardson wrote: > > I am most worried that we really have no process here to make a decision. How about rough consensus and running code? - Mark > > > -- > Michael Richardson , Sandelman Software Works > > > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From lorenzo@google.com Fri Feb 7 02:35:33 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92E791A05C7 for ; Fri, 7 Feb 2014 02:35:33 -0800 (PST) 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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IFchxev_8Twd for ; Fri, 7 Feb 2014 02:35:31 -0800 (PST) Received: from mail-qa0-x22f.google.com (mail-qa0-x22f.google.com [IPv6:2607:f8b0:400d:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 822491A00B4 for ; Fri, 7 Feb 2014 02:35:31 -0800 (PST) Received: by mail-qa0-f47.google.com with SMTP id j5so4893793qaq.34 for ; Fri, 07 Feb 2014 02:35:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=uUDZdoylwONOUIyWR4YfYs/XmD/3XGGLj6RUcSdIpnU=; b=HL0yAFqCwXrX/XD/j1r4KvVfg+Xd1U9efMQVh1fNZLMw3LUlJX86CNdylo37l3GH9b iZPCN8pDL4zAfNoX+ydHzlc54xEMvjS/kG8VCLGbe4o992gT1/pBE7j5xdOt+qn+p6T4 i37fy65Pgcsr9dPLDv2imGUzaZySPBZLjSjp/xlnLaUZ9kI2VEC1RQIAm7yegaL3NQPR Mt66LEUefAMoaMvw3wStKTwrGQqbjKXxC2DThHERNgm9wnLJoky/S22CLV7YbqBNlWqz yjSo8wRzrxbTsGlGCtXb0FOTsWm6uuAm0pVnGdP1aREKyydzy6V2mDAg/hmn4e/2mpxs L3+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=uUDZdoylwONOUIyWR4YfYs/XmD/3XGGLj6RUcSdIpnU=; b=C+qpHwHHLAVlog1rgOgvGF1k2PuV7y8Y3W+MPp3UlzxtQiMv533lRuLOg5wK01v9fi h+Sfsey99M3J4qOCvBcSBc46MsgIr+XvowXLTXOLs2UlkZNFhgy7G6HcA6TlHtG3iTBy D1n7npKODIfKUPKdY+gNPgd6Hh7t80PfthV11ujtnuZ4Qcoa1xjEjVRU7vT1gTzfb2nt 6oy/7hn+p4vy8r8oPxb+FCseUzenrXQ1kxfrTTlVLrCX4JjDB1vdFImNppZ4en7HdV/U /qrV6WS7iQG0q+kYuXXu1eHBYd9MBGvybBO7aFfPU5sOUkiwwvlLG3qbUFjTbXE2eDgM EjmA== X-Gm-Message-State: ALoCoQlK/7xHkP5B8XeozDXNiB7ZOfyxXWIIR0z6QOvV8aWfQaZReSbC4c/Oi15YOfo9vpiFHwRDX8hoT9Gc5DbJqP3aqyaLsp+Sw+c9OzC9yYDN3fpbiFAHvkngB1h0KhaVGS2OJJHYCtBgRovEpZrk8avI/DjbfLC9dR/+raoQXI0ff6t0QWoBq5O7WDd3wST1E344EvTB X-Received: by 10.224.160.195 with SMTP id o3mr20463644qax.98.1391769329972; Fri, 07 Feb 2014 02:35:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.234.193 with HTTP; Fri, 7 Feb 2014 02:35:09 -0800 (PST) In-Reply-To: <51637E3C-7BA6-4AB2-96C3-1B23C6F15C9D@townsley.net> References: <52EA3361.1010501@gmail.com> <2EB6289E-C7FD-481F-99F9-E35730245943@employees.org> <52EA442D.3020707@gmail.com> <52EA47AA.90302@gmail.com> <1FE00515-A7AD-4C48-A7F2-63BA8696D818@darou.fr> <52EA4BB1.9010607@gmail.com> <2922CC94-540D-4215-899B-4722BD1C5EBC@employees.org> <52EF90BD.4070701@gmail.com> <18C8BE29C547CC4DBBCF3C4F0B8EC1780608ED@wds-exc1.okna.nominet.org.uk> <8B52F0C3-EB5A-48D1-9596-52302F6A4A3C@darou.fr> <8FA52BBD-9A61-4795-9BA3-AB8B0A63EB98@fugue.com> <29DCB6B2-B428-4B45-8796-ACB09E40376A@fugue.com> <26945.1391525921@sandelman.ca> <2BE96E0A-D9A7-492F-B07F-9C83767C6F0D@darou.fr> <445.1391555635@sandelman.ca> <52F1A6D6.8020801@gmail.com> <52F22AF1.6060300@gmail.com> <52F28DD4.8000104@gmail.com> <51637E3C-7BA6-4AB2-96C3-1B23C6F15C9D@townsley.net> From: Lorenzo Colitti Date: Fri, 7 Feb 2014 19:35:09 +0900 Message-ID: To: Mark Townsley Content-Type: multipart/alternative; boundary=089e0153695c85d60204f1ce8ced Cc: Alexandru Petrescu , "homenet@ietf.org" Subject: Re: [homenet] DSCP (was: Prefix semantics (not) [was: DHCP PD]) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 10:35:33 -0000 --089e0153695c85d60204f1ce8ced Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Mark, It is a controlled domain. ISPs do filter packets from their users, because of BCP 38. DSCP is no harder than source address filtering. Please let's stop bringing to the table technical arguments that don't hold water, ok? I'd much rather hear "we want this to be standardized because DT has implemented it" - at least that's the truth. :-) Cheers, Lorenzo On Fri, Feb 7, 2014 at 7:26 PM, Mark Townsley wrote: > > Brian, > > As you point out, DSCP does of course work between endpoints within an > enterprise network just as it was designed to do. It's reasonable to thin= k > that the same technology could be used in other environments, but the tra= ck > record of it doing so outside of a tightly controlled domain is rather > poor. Reclassifying at boundaries is expensive, often inaccurate, and > ultimately doomed as we encrypt more and more end to end. It would be gre= at > if diffserv worked across the Internet, multicast would be nice as well. > But, heck, we can't even get PMTUD working well enough to truly depend on= . > > - Mark > > > > On Feb 5, 2014, at 8:15 PM, Brian E Carpenter wrote: > > > On 06/02/2014 01:13, Alexandru Petrescu wrote: > >> Le 05/02/2014 09:06, Mikael Abrahamsson a =C3=A9crit : > >>> On Wed, 5 Feb 2014, Brian E Carpenter wrote: > >>> > >>>> On 05/02/2014 12:13, Michael Richardson wrote: > >>>>> Pierre Pfister wrote: > >>>> ... > >>>>>> For instance, if a prefix is for general purpose, and another is f= or > >>>>>> voice > >>>>>> applications, then hosts may only get addresses for voice > >>>>>> application, and > >>>>>> would therefore not being able to access the internet. > >>>> > >>>> Yes, that's one of many reasons why using prefixes to distinguish > >>>> types of traffic is a really bad idea. > >>> > >>> The idea is that "non color-aware" devices will only use the "Interne= t" > >>> prefix, by means of the colored prefixes will use a different ND PIO > >>> type for prefix announcement (thus invisible to these non color-aware > >>> hosts), plus DHCPv6 server would only hand out prefixes/addresses to > >>> hosts that request them. > >> > >> A color could also be a particular value for the flow label field. > > > > No, a DSCP. The flow label value is supposed to be opaque with > > no semantics. > > > > We designed diffserv for this purpose and it works well and is quite > > widely used in corporate networks. Wasting prefixes to distinguish > > traffic types is an incredibly bad idea. > > > > 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 > --089e0153695c85d60204f1ce8ced Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Mark,

It is a controlled dom= ain.
ISPs do filter packets from their users, because of BCP 38.<= /div>DSCP is no harder than source address filtering.

Pl= ease let's stop bringing to the table technical arguments that don'= t hold water, ok? I'd much rather hear "we want this to be standar= dized because DT has implemented it" - at least that's the truth. = :-)

Cheers,
Lorenzo


On Fri, Feb 7, 2014 at 7:26 PM,= Mark Townsley <mark@townsley.net> wrote:

Brian,

As you point out, DSCP does of course work between endpoints within an ente= rprise network just as it was designed to do. It's reasonable to think = that the same technology could be used in other environments, but the track= record of it doing so outside of a tightly controlled domain is rather poo= r. Reclassifying at boundaries is expensive, often inaccurate, and ultimate= ly doomed as we encrypt more and more end to end. It would be great if diff= serv worked across the Internet, multicast would be nice as well. But, heck= , we can't even get PMTUD working well enough to truly depend on.

- Mark



On Feb 5, 2014, at 8:15 PM, Brian E Carpenter wrote:

> On 06/02/2014 01:13, Alexandru Petrescu wrote:
>> Le 05/02/2014 09:06, Mikael Abrahamsson a =C3=A9crit :
>>> On Wed, 5 Feb 2014, Brian E Carpenter wrote:
>>>
>>>> On 05/02/2014 12:13, Michael Richardson wrote:
>>>>> Pierre Pfister <pierre.pfister@darou.fr> wrote:
>>>> ...
>>>>>> For instance, if a prefix is for general purpose, = and another is for
>>>>>> voice
>>>>>> applications, then hosts may only get addresses fo= r voice
>>>>>> application, and
>>>>>> would therefore not being able to access the inter= net.
>>>>
>>>> Yes, that's one of many reasons why using prefixes to = distinguish
>>>> types of traffic is a really bad idea.
>>>
>>> The idea is that "non color-aware" devices will only= use the "Internet"
>>> prefix, by means of the colored prefixes will use a different = ND PIO
>>> type for prefix announcement (thus invisible to these non colo= r-aware
>>> hosts), plus DHCPv6 server would only hand out prefixes/addres= ses to
>>> hosts that request them.
>>
>> A color could also be a particular value for the flow label field.=
>
> No, a DSCP. The flow label value is supposed to be opaque with
> no semantics.
>
> We designed diffserv for this purpose and it works well and is quite > widely used in corporate networks. Wasting prefixes to distinguish
> traffic types is an incredibly bad idea.
>
> =C2=A0 =C2=A0 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

--089e0153695c85d60204f1ce8ced-- From lorenzo@google.com Fri Feb 7 03:08:44 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CB401A1EE8 for ; Fri, 7 Feb 2014 03:08:44 -0800 (PST) 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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aIJ_D-YvHsOc for ; Fri, 7 Feb 2014 03:08:42 -0800 (PST) Received: from mail-qa0-x22e.google.com (mail-qa0-x22e.google.com [IPv6:2607:f8b0:400d:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 3437B1A8035 for ; Fri, 7 Feb 2014 03:02:41 -0800 (PST) Received: by mail-qa0-f46.google.com with SMTP id ii20so4834056qab.19 for ; Fri, 07 Feb 2014 03:02:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=XvBnF1Dz7XHkcpdsvldW4cEq2So3tE3tW52RFGWsE88=; b=XsBatQsXNEzhkSuBiWJBXhT3NN4k3aSZvOfGPuWha1QoElHDDET/AXOIZc67I5sYpD xLd4eFDBMD2bvJVHW+wyMXumvHsof+bmTCod6fI3okiqlkxTaY1BNvkt4xlZhms6X5yx A2+W/C1e9DqpAID52OvSK6T0L3gbwa5jS36mrETMwKzeyop02m4hqUHjExRcKP4ht5XL Kat706lZ7XhdhFmx7mZzub0afUNg8pma1DDUHZAYfgu83ZCjhBuhGwPQi7xNC6eFdoao r7T9OoSAZGxNKuipIuTWM551YAYSQAr/uAl8MrVrDntcDi3HM4soD2T5uXF+mH5Kxu7p xp1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=XvBnF1Dz7XHkcpdsvldW4cEq2So3tE3tW52RFGWsE88=; b=f20AEZ4pRWSY1lIyobnmVGS0POhKmDnk5QeBkggC+RGAoOtH649uLNveQlC8l6cjev r6YsMwejean5FW8boMtt2iV2caGY13ybned8vJZ5/Pl43y7kb5fem/mbaTdePG28+zLW CiFPqV1jDS07lhpIpRulhY5e1A5Wm3IvkOglbHixV7wXDirRF1PtZlBTCBVqC19OR/xx a4tUv9v8gHsl9VoMaTdQB7m+qBtbSBgfT7vwwd2OUk9qcTaMb6sC+VepE32xIJR+gVjR QuwTGxFN0EbjbEsA3K0Py/2m32Gu5mFMqPTPYPY61wJQbRu0Gtp84Co0NsfoCQmJyEjs LuWw== X-Gm-Message-State: ALoCoQm1KuGihPag7NFpraxuUU3dUh2YgQ9/iXH6lOA3pK4/2T3aVNUpDiWdDIhotROjDmLeQE4fuohUCemVQTAxVU5bxhFhy6LyS3DsQsD0OF1OQ+NiSHoXZgM24qOAVp1B5M2lLJ5Ceje144mfQa662hmAOB4f4guXbt1X28PNOmSl4WnXmWmaOKD9YizYNcyUs8I6OdGj X-Received: by 10.229.84.198 with SMTP id k6mr3575274qcl.20.1391770960925; Fri, 07 Feb 2014 03:02:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.234.193 with HTTP; Fri, 7 Feb 2014 03:02:20 -0800 (PST) In-Reply-To: References: <52EA47AA.90302@gmail.com> <1FE00515-A7AD-4C48-A7F2-63BA8696D818@darou.fr> <52EA4BB1.9010607@gmail.com> <2922CC94-540D-4215-899B-4722BD1C5EBC@employees.org> <52EF90BD.4070701@gmail.com> <18C8BE29C547CC4DBBCF3C4F0B8EC1780608ED@wds-exc1.okna.nominet.org.uk> <8B52F0C3-EB5A-48D1-9596-52302F6A4A3C@darou.fr> <8FA52BBD-9A61-4795-9BA3-AB8B0A63EB98@fugue.com> <29DCB6B2-B428-4B45-8796-ACB09E40376A@fugue.com> <26945.1391525921@sandelman.ca> <2BE96E0A-D9A7-492F-B07F-9C83767C6F0D@darou.fr> <445.1391555635@sandelman.ca> <52F1A6D6.8020801@gmail.com> <52F22AF1.6060300@gmail.com> <52F28DD4.8000104@gmail.com> <51637E3C-7BA6-4AB2-96C3-1B23C6F15C9D@townsley.net> From: Lorenzo Colitti Date: Fri, 7 Feb 2014 20:02:20 +0900 Message-ID: To: Mikael Abrahamsson Content-Type: multipart/alternative; boundary=001a1134541abc3ae904f1ceed8d Cc: "homenet@ietf.org" Subject: Re: [homenet] DSCP (was: Prefix semantics (not) [was: DHCP PD]) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 11:08:44 -0000 --001a1134541abc3ae904f1ceed8d Content-Type: text/plain; charset=UTF-8 On Fri, Feb 7, 2014 at 7:57 PM, Mikael Abrahamsson wrote: > It is a controlled domain. >> ISPs do filter packets from their users, because of BCP 38. >> DSCP is no harder than source address filtering. >> > > Absolutely, but it means resetting DSCP, thus breaking QoS in other parts > of the packet path. Well to be more precise, it means making sure DSCP is a value that the customer is allowed to use (or rewriting it). Just like you have to make sure that the packet's source address is a value that the customer is allowed to use (or dropping the packet). No? --001a1134541abc3ae904f1ceed8d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Feb 7, 2014 at 7:57 PM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
It is a = controlled domain.
ISPs do filter packets from their users, because of BCP 38.
DSCP is no harder than source address filtering.

Absolutely, but it means resetting DSCP, thus breaking QoS in other parts o= f the packet path.

Well to be more precise,= it means making sure DSCP is a value that the customer is allowed to use (= or rewriting it). Just like you have to make sure that the packet's sou= rce address is a value that the customer is allowed to use (or dropping the= packet). No?
--001a1134541abc3ae904f1ceed8d-- From swmike@swm.pp.se Fri Feb 7 03:12:51 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33F7D1A05FD for ; Fri, 7 Feb 2014 03:12:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.486 X-Spam-Level: X-Spam-Status: No, score=-1.486 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, J_CHICKENPOX_31=0.6, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CzE4Fq8inRtj for ; Fri, 7 Feb 2014 03:12:49 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 898A11A16F0 for ; Fri, 7 Feb 2014 03:06:18 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id B9D839C; Fri, 7 Feb 2014 11:57:38 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id B28399A; Fri, 7 Feb 2014 11:57:38 +0100 (CET) Date: Fri, 7 Feb 2014 11:57:38 +0100 (CET) From: Mikael Abrahamsson To: Lorenzo Colitti In-Reply-To: Message-ID: References: <52EA47AA.90302@gmail.com> <1FE00515-A7AD-4C48-A7F2-63BA8696D818@darou.fr> <52EA4BB1.9010607@gmail.com> <2922CC94-540D-4215-899B-4722BD1C5EBC@employees.org> <52EF90BD.4070701@gmail.com> <18C8BE29C547CC4DBBCF3C4F0B8EC1780608ED@wds-exc1.okna.nominet.org.uk> <8B52F0C3-EB5A-48D1-9596-52302F6A4A3C@darou.fr> <8FA52BBD-9A61-4795-9BA3-AB8B0A63EB98@fugue.com> <29DCB6B2-B428-4B45-8796-ACB09E40376A@fugue.com> <26945.1391525921@sandelman.ca> <2BE96E0A-D9A7-492F-B07F-9C83767C6F0D@darou.fr> <445.1391555635@sandelman.ca> <52F1A6D6.8020801@gmail.com> <52F22AF1.6060300@gmail.com> <52F28DD4.8000104@gmail.com> <51637E3C-7BA6-4AB2-96C3-1B23C6F15C9D@townsley.net> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "homenet@ietf.org" Subject: Re: [homenet] DSCP (was: Prefix semantics (not) [was: DHCP PD]) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 11:12:51 -0000 On Fri, 7 Feb 2014, Lorenzo Colitti wrote: > > It is a controlled domain. > ISPs do filter packets from their users, because of BCP 38. > DSCP is no harder than source address filtering. Absolutely, but it means resetting DSCP, thus breaking QoS in other parts of the packet path. > Please let's stop bringing to the table technical arguments that don't hold > water, ok? I'd much rather hear "we want this to be standardized because DT > has implemented it" - at least that's the truth. :-) Let's agree that there are many ways to skin a cat and different ways have different pro:s and con:s. -- Mikael Abrahamsson email: swmike@swm.pp.se From swmike@swm.pp.se Fri Feb 7 03:20:49 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B6CD1A05F5 for ; Fri, 7 Feb 2014 03:20:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.386 X-Spam-Level: X-Spam-Status: No, score=-4.386 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WFlH3CH_sCLX for ; Fri, 7 Feb 2014 03:20:48 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by ietfa.amsl.com (Postfix) with ESMTP id C5BF81A1EF0 for ; Fri, 7 Feb 2014 03:20:03 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 6EA3D9C; Fri, 7 Feb 2014 12:20:03 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 6554A9A; Fri, 7 Feb 2014 12:20:03 +0100 (CET) Date: Fri, 7 Feb 2014 12:20:03 +0100 (CET) From: Mikael Abrahamsson To: Lorenzo Colitti In-Reply-To: Message-ID: References: <52EA4BB1.9010607@gmail.com> <2922CC94-540D-4215-899B-4722BD1C5EBC@employees.org> <52EF90BD.4070701@gmail.com> <18C8BE29C547CC4DBBCF3C4F0B8EC1780608ED@wds-exc1.okna.nominet.org.uk> <8B52F0C3-EB5A-48D1-9596-52302F6A4A3C@darou.fr> <8FA52BBD-9A61-4795-9BA3-AB8B0A63EB98@fugue.com> <29DCB6B2-B428-4B45-8796-ACB09E40376A@fugue.com> <26945.1391525921@sandelman.ca> <2BE96E0A-D9A7-492F-B07F-9C83767C6F0D@darou.fr> <445.1391555635@sandelman.ca> <52F1A6D6.8020801@gmail.com> <52F22AF1.6060300@gmail.com> <52F28DD4.8000104@gmail.com> <51637E3C-7BA6-4AB2-96C3-1B23C6F15C9D@townsley.net> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "homenet@ietf.org" Subject: Re: [homenet] DSCP (was: Prefix semantics (not) [was: DHCP PD]) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 11:20:49 -0000 On Fri, 7 Feb 2014, Lorenzo Colitti wrote: >> Absolutely, but it means resetting DSCP, thus breaking QoS in other parts >> of the packet path. > > Well to be more precise, it means making sure DSCP is a value that the > customer is allowed to use (or rewriting it). Just like you have to make > sure that the packet's source address is a value that the customer is > allowed to use (or dropping the packet). No? Correct. -- Mikael Abrahamsson email: swmike@swm.pp.se From mark@townsley.net Fri Feb 7 03:44:52 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DEBF1A16F0 for ; Fri, 7 Feb 2014 03:44:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id up_e4aoZqqMR for ; Fri, 7 Feb 2014 03:44:49 -0800 (PST) Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) by ietfa.amsl.com (Postfix) with ESMTP id 16C681A0605 for ; Fri, 7 Feb 2014 03:44:48 -0800 (PST) Received: by mail-wi0-f169.google.com with SMTP id e4so730680wiv.2 for ; Fri, 07 Feb 2014 03:44:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=ihcxQ7WI/b7ZJ1TQaXSXqIA0u7p6EfgjwiWO6luSGow=; b=X/8AWrIiYzP8MTrrs3g8OQjf3pAeS6GzFImb4owzkxZkyiz2VUgYpqF0FUcHIUbXqb a5yRy8oviEAcVYC5OFYwA02pgp63ZlPvVNskX0hrJyqzWaUn6HmKiBGqWq5WsjAEvMK/ Ky4WefGZg0dgtgbzMTS0TMfRczI+AQ9ay1z8iOGFMnFwY3bcy3ub77hwwme4vghEfYCV TeB5kXz+mfiidr/P4tm42mOc6iGowO+3RAw3txuHqfKlvsbhNiwh26dhzsy4fxp4A4LK gSWnw0dOfNbbNSa0JxrH0cqlQRHpHmuwO3IxC9dHV+oHZWeCDUEQXSid/1b53n51VCBu rzRQ== X-Gm-Message-State: ALoCoQl6eZw0Xm0Zf6a+opKqLfLBoYRutWv/+8Io+pYTCqGTAl/Bwci3/KtZRaIiiDYS8TH0g8zQ X-Received: by 10.180.76.168 with SMTP id l8mr3572344wiw.40.1391773488522; Fri, 07 Feb 2014 03:44:48 -0800 (PST) Received: from pc14.home (AMontsouris-653-1-24-200.w92-141.abo.wanadoo.fr. [92.141.7.200]) by mx.google.com with ESMTPSA id e5sm10049655wja.15.2014.02.07.03.44.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 07 Feb 2014 03:44:45 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_1F59F7B0-1C75-4A0B-B2B9-5DD280B54BD5" From: Mark Townsley In-Reply-To: Date: Fri, 7 Feb 2014 12:44:45 +0100 Message-Id: <3251603B-6E8E-48BC-8352-1534D7838B4C@townsley.net> References: <52EA3361.1010501@gmail.com> <2EB6289E-C7FD-481F-99F9-E35730245943@employees.org> <52EA442D.3020707@gmail.com> <52EA47AA.90302@gmail.com> <1FE00515-A7AD-4C48-A7F2-63BA8696D818@darou.fr> <52EA4BB1.9010607@gmail.com> <2922CC94-540D-4215-899B-4722BD1C5EBC@employees.org> <52EF90BD.4070701@gmail.com> <18C8BE29C547CC4DBBCF3C4F0B8EC1780608ED@wds-exc1.okna.nominet.org.uk> <8B52F0C3-EB5A-48D1-9596-52302F6A4A3C@darou.fr> <8FA52BBD-9A61-4795-9BA3-AB8B0A63EB98@fugue.com> <29DCB6B2-B428-4B45-8796-ACB09E40376A@fugue.com> <26945.1391525921@sandelman.ca> <2BE96E0A-D9A7-492F-B07F-9C83767C6F0D@darou.fr> <445.1391555635@sandelman.ca> <52F1A6D6.8020801@gmail.com> <52F22AF1.6060300@gmail.com> <52F28DD4.8000104@gmail.com> <51637E3C-7BA6-4AB2-96C3-1B23C6F15C9D@townsley.net> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1283) Cc: Alexandru Petrescu , "homenet@ietf.org" Subject: Re: [homenet] DSCP (was: Prefix semantics (not) [was: DHCP PD]) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 11:44:52 -0000 --Apple-Mail=_1F59F7B0-1C75-4A0B-B2B9-5DD280B54BD5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Lorenzo, On Feb 7, 2014, at 11:35 AM, Lorenzo Colitti wrote: > Mark, >=20 > It is a controlled domain. > ISPs do filter packets from their users, because of BCP 38. > DSCP is no harder than source address filtering. It's not about whether treating the packet is hard technically on the = forwarding engine, it's about whether you can trust whether the bits are = set correctly and persevered where the operator expects them to. For = DSCP, we even have difficulties with that across vendors in enterprise = deployments. As trust is something that is built up over time, and DSCP = has indeed been around quite a while, there's a lot of baggage to get = past here.=20 Operationally, I don't think BCP38 filtering and QoS treatment based on = DSCP is a fair comparison at all. If your NAT sets the wrong source IP = address bits and your packets get dropped by your ISP, you lose service = entirely. Bad DSCP bits, unless being monitored closely by someone or = some tool, likely results in intermittent service issues based on what = mix of traffic is present at any given time. Rather than the problem = getting resolved, the user just hangs up and calls on his mobile phone = (or whatever), and then the problem just "goes away" later, until it = comes back again.. Rinse. Repeat. > Please let's stop bringing to the table technical arguments that don't = hold water, ok? I'd much rather hear "we want this to be > standardized because DT has implemented it" - at least that's the = truth. :-) I tried to stay out of the "semantic" discussion, but you're going to = put me in it anyway. Here's my thought on that. We most often think about reducing the NAPT complexity above IPv4 by = moving to IPv6, but there is a plethora of complexity below that IPv6 = has the chance to collapse. In a greenfield IPv6 design, once you wipe = away all the VLANs, overlays, etc... the inertia from that exercise = alone can lead to looking at addresses for more than numbering exposed = physical network interfaces alone. I've seen this again and again, and = it is just this point where one person's convenient use of IP addressing = becomes another's evil semantic horror. That makes sense, because once = you pass the least common denominator of a physical network interface, = you are necessarily more and more domain-specific, which is where most = misunderstandings and arguments tend to occur.=20 This seems like a "Tussle", quoting [Clark], et. al...=20 "Design for variation in outcome, so that the outcome can be different = in different places, and the tussle takes place within the design, not = by distorting or violating it. Do not design so as to dictate the = outcome. Rigid designs will be broken; designs that permit variation = will flex under pressure and survive."=20 You asked for Truth. Truth is that homes need multiple prefixes for = multihoming to different ISPs. Reality is, if DT wants to use that to = expose 3 VLANs or 3 networks making it look like 3 ISPs to the homenet, = so be it. In fact, it's a good test case to ensure the multiprefix = design is implemented and flexible enough to handle cases we don't = immediately envision.=20 - Mark [Clark] = http://groups.csail.mit.edu/ana/Publications/PubPDFs/Tussle2002.pdf >=20 > Cheers, > Lorenzo >=20 >=20 > On Fri, Feb 7, 2014 at 7:26 PM, Mark Townsley = wrote: >=20 > Brian, >=20 > As you point out, DSCP does of course work between endpoints within an = enterprise network just as it was designed to do. It's reasonable to = think that the same technology could be used in other environments, but = the track record of it doing so outside of a tightly controlled domain = is rather poor. Reclassifying at boundaries is expensive, often = inaccurate, and ultimately doomed as we encrypt more and more end to = end. It would be great if diffserv worked across the Internet, multicast = would be nice as well. But, heck, we can't even get PMTUD working well = enough to truly depend on. >=20 > - Mark >=20 >=20 >=20 > On Feb 5, 2014, at 8:15 PM, Brian E Carpenter wrote: >=20 > > On 06/02/2014 01:13, Alexandru Petrescu wrote: > >> Le 05/02/2014 09:06, Mikael Abrahamsson a =E9crit : > >>> On Wed, 5 Feb 2014, Brian E Carpenter wrote: > >>> > >>>> On 05/02/2014 12:13, Michael Richardson wrote: > >>>>> Pierre Pfister wrote: > >>>> ... > >>>>>> For instance, if a prefix is for general purpose, and another = is for > >>>>>> voice > >>>>>> applications, then hosts may only get addresses for voice > >>>>>> application, and > >>>>>> would therefore not being able to access the internet. > >>>> > >>>> Yes, that's one of many reasons why using prefixes to distinguish > >>>> types of traffic is a really bad idea. > >>> > >>> The idea is that "non color-aware" devices will only use the = "Internet" > >>> prefix, by means of the colored prefixes will use a different ND = PIO > >>> type for prefix announcement (thus invisible to these non = color-aware > >>> hosts), plus DHCPv6 server would only hand out prefixes/addresses = to > >>> hosts that request them. > >> > >> A color could also be a particular value for the flow label field. > > > > No, a DSCP. The flow label value is supposed to be opaque with > > no semantics. > > > > We designed diffserv for this purpose and it works well and is quite > > widely used in corporate networks. Wasting prefixes to distinguish > > traffic types is an incredibly bad idea. > > > > brian > > > > _______________________________________________ > > homenet mailing list > > homenet@ietf.org > > https://www.ietf.org/mailman/listinfo/homenet >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet >=20 --Apple-Mail=_1F59F7B0-1C75-4A0B-B2B9-5DD280B54BD5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
Mark,

It is a controlled = domain.
ISPs do filter packets from their users, because of = BCP 38.
DSCP is no harder than source address = filtering.

It's not about whether = treating the packet is hard technically on the forwarding engine, it's = about whether you can trust whether the bits are set correctly and = persevered where the operator expects them to. For DSCP, we even have = difficulties with that across vendors in enterprise deployments. As = trust is something that is built up over time, and DSCP has indeed been = around quite a while, there's a lot of baggage to get past = here. 

Operationally, I don't think BCP38 = filtering and QoS treatment based on DSCP is a fair comparison at all. = If your NAT sets the wrong source IP address bits and your packets get = dropped by your ISP, you lose service entirely. Bad DSCP bits, unless = being monitored closely by someone or some tool, likely results in = intermittent service issues based on what mix of traffic is present at = any given time. Rather than the problem getting resolved, the user just = hangs up and calls on his mobile phone (or whatever), and then the = problem just "goes away" later, until it comes back again.. Rinse. = Repeat.

Please let's stop bringing to the table technical = arguments that don't hold water, ok? I'd much rather hear "we want = this to be
standardized because DT has implemented it" - at least = that's the truth. :-)

I = tried to stay out of the "semantic" discussion, but you're going to put = me in it anyway. Here's my thought on that.

We = most often think about reducing the NAPT complexity above IPv4 by moving = to IPv6, but there is a plethora of complexity below  that IPv6 has = the chance to collapse. In a greenfield IPv6 design, once you wipe away = all the VLANs, overlays, etc... the inertia from that exercise alone can = lead to looking at addresses for more than numbering exposed physical = network interfaces alone. I've seen this again and again, and it is just = this point where one person's convenient use of IP addressing = becomes another's evil semantic horror. That makes sense, because once = you pass the least common denominator of a physical network interface, = you are necessarily more and more domain-specific, which is where most = misunderstandings and arguments tend to = occur. 

This seems like a "Tussle", = quoting [Clark], et. al... 

"Design for = variation in outcome, so that the outcome can be different in different = places, and the tussle takes place within the design, not by distorting = or violating it. Do not design so as to dictate the outcome. Rigid = designs will be broken; designs that permit variation will flex under = pressure and survive." 

You asked for = Truth. Truth is that homes need multiple prefixes for multihoming to = different ISPs. Reality is, if DT wants to use that to expose 3 VLANs or = 3 networks making it look like 3 ISPs to the homenet, so be it. In = fact, it's a good test case to ensure the multiprefix design is = implemented and flexible enough to handle cases we don't immediately = envision. 

- = Mark




Cheers,
Lorenzo


On Fri, Feb 7, = 2014 at 7:26 PM, Mark Townsley <mark@townsley.net> wrote:

Brian,

As you point out, DSCP does of course work between endpoints within an = enterprise network just as it was designed to do. It's reasonable to = think that the same technology could be used in other environments, but = the track record of it doing so outside of a tightly controlled domain = is rather poor. Reclassifying at boundaries is expensive, often = inaccurate, and ultimately doomed as we encrypt more and more end to = end. It would be great if diffserv worked across the Internet, multicast = would be nice as well. But, heck, we can't even get PMTUD working well = enough to truly depend on.

- Mark



On Feb 5, 2014, at 8:15 PM, Brian E Carpenter wrote:

> On 06/02/2014 01:13, Alexandru Petrescu wrote:
>> Le 05/02/2014 09:06, Mikael Abrahamsson a =E9crit :
>>> On Wed, 5 Feb 2014, Brian E Carpenter wrote:
>>>
>>>> On 05/02/2014 12:13, Michael Richardson wrote:
>>>>> Pierre Pfister <pierre.pfister@darou.fr> = wrote:
>>>> ...
>>>>>> For instance, if a prefix is for general = purpose, and another is for
>>>>>> voice
>>>>>> applications, then hosts may only get addresses = for voice
>>>>>> application, and
>>>>>> would therefore not being able to access the = internet.
>>>>
>>>> Yes, that's one of many reasons why using prefixes to = distinguish
>>>> types of traffic is a really bad idea.
>>>
>>> The idea is that "non color-aware" devices will only use = the "Internet"
>>> prefix, by means of the colored prefixes will use a = different ND PIO
>>> type for prefix announcement (thus invisible to these non = color-aware
>>> hosts), plus DHCPv6 server would only hand out = prefixes/addresses to
>>> hosts that request them.
>>
>> A color could also be a particular value for the flow label = field.
>
> No, a DSCP. The flow label value is supposed to be opaque with
> no semantics.
>
> We designed diffserv for this purpose and it works well and is = quite
> widely used in corporate networks. Wasting prefixes to = distinguish
> traffic types is an incredibly bad idea.
>
>     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


= --Apple-Mail=_1F59F7B0-1C75-4A0B-B2B9-5DD280B54BD5-- From brian.e.carpenter@gmail.com Fri Feb 7 11:48:46 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 266F81A048E for ; Fri, 7 Feb 2014 11:48:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zfy7-_BF_IvP for ; Fri, 7 Feb 2014 11:48:43 -0800 (PST) Received: from mail-pb0-x22a.google.com (mail-pb0-x22a.google.com [IPv6:2607:f8b0:400e:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 2B1431A01D2 for ; Fri, 7 Feb 2014 11:48:42 -0800 (PST) Received: by mail-pb0-f42.google.com with SMTP id jt11so3705207pbb.1 for ; Fri, 07 Feb 2014 11:48:42 -0800 (PST) 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=1HntVI86YDPUPAhFJPeAiSqFc6IaeYFUDFAsjh4kcig=; b=z+bPVRF4doPR6TPM+K4cuLzSddd321Qtgg/aGftiZXKYFveUdXNXsBVi++HJWCc+im Cy3cSXgbrRZmsp2qmmuqN6QLXKu7Qf66hxz69ITZEyml3FmFNczxJ/7fcv/yxpNDCr1M Dq6Dgr8I6yuSsO2/Oe0b9YfaCgAvmOpNkTOYuImhfZDBvDFcppJJAdWLtelqKUi0QIwh xlg+nf/r2I/bnaOCAICQHwLYs7s7AAvILPRTjE5E+4EompSUsfMpQBb2qRdF2Hjn4tcM SoirFI1C4rn94Qf7TsIsXaGPPBzHLPDf3UwI4pHZtrB3oTJWXWywoqDrwsOdWX96fTkI 3hTA== X-Received: by 10.66.11.202 with SMTP id s10mr10119589pab.86.1391802522016; Fri, 07 Feb 2014 11:48:42 -0800 (PST) Received: from [192.168.178.23] (208.199.69.111.dynamic.snap.net.nz. [111.69.199.208]) by mx.google.com with ESMTPSA id qq5sm16364060pbb.24.2014.02.07.11.48.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 07 Feb 2014 11:48:41 -0800 (PST) Message-ID: <52F538A4.6090004@gmail.com> Date: Sat, 08 Feb 2014 08:48:52 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mikael Abrahamsson References: <2922CC94-540D-4215-899B-4722BD1C5EBC@employees.org> <52EF90BD.4070701@gmail.com> <18C8BE29C547CC4DBBCF3C4F0B8EC1780608ED@wds-exc1.okna.nominet.org.uk> <8B52F0C3-EB5A-48D1-9596-52302F6A4A3C@darou.fr> <8FA52BBD-9A61-4795-9BA3-AB8B0A63EB98@fugue.com> <29DCB6B2-B428-4B45-8796-ACB09E40376A@fugue.com> <26945.1391525921@sandelman.ca> <2BE96E0A-D9A7-492F-B07F-9C83767C6F0D@darou.fr> <445.1391555635@sandelman.ca> <52F1A6D6.8020801@gmail.com> <52F22AF1.6060300@gmail.com> <52F28DD4.8000104@gmail.com> <51637E3C-7BA6-4AB2-96C3-1B23C6F15C9D@townsley.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "homenet@ietf.org" , Lorenzo Colitti Subject: Re: [homenet] DSCP X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 19:48:46 -0000 On 08/02/2014 00:20, Mikael Abrahamsson wrote: > On Fri, 7 Feb 2014, Lorenzo Colitti wrote: > >>> Absolutely, but it means resetting DSCP, thus breaking QoS in other >>> parts >>> of the packet path. >> >> Well to be more precise, it means making sure DSCP is a value that the >> customer is allowed to use (or rewriting it). Just like you have to make >> sure that the packet's source address is a value that the customer is >> allowed to use (or dropping the packet). No? > > Correct. Yes. There's nothing we've discussed in this thread that is different from the diffserv architecture (RFC 2475). Diffserv works within a single administrative domain (possibly split up using tunnels). There are some efforts towards inter-provider diffserv in TSVWG (RFC 4594, RFC 5127, draft-geib-tsvwg-diffserv-intercon). Brian From mark@townsley.net Fri Feb 7 13:51:22 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29AC01A0506 for ; Fri, 7 Feb 2014 13:51:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id znPmamLYVCEd for ; Fri, 7 Feb 2014 13:51:20 -0800 (PST) Received: from mail-ea0-f174.google.com (mail-ea0-f174.google.com [209.85.215.174]) by ietfa.amsl.com (Postfix) with ESMTP id 8C0111A04B2 for ; Fri, 7 Feb 2014 13:51:20 -0800 (PST) Received: by mail-ea0-f174.google.com with SMTP id b10so1827626eae.33 for ; Fri, 07 Feb 2014 13:51:19 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=/ZeJS7zzhZTw2qLdYkqxaXTE/lhzT5bTaIAumNXA7o8=; b=Z0EYoMNNXu3KjbPq5KwzO3r61Sw/GFeUheCDFgvWxdgdZekxd2C0Zn6qY8cDJBpNio 9DtxCpQmQ7eXBh1Ipth8iOvopnQJI0/AbAlDhTS451jwFtvU8CuC2FRQDGByg5350S/q Fr+98X/KfUcATVGxfnoupFozyCKS9fwYAllXD00TTyt33fH3zzOsSRYWd9ofRE/W3vt3 Raxliqh9WKpsEkpqrYUWRZtftErVfcZqdCKeTRSfgZp6YMp3zRHGVBH26ymgQPAgJBtd wIrpaDLbz0O9jSTTb+fY/0SOYb34e5NSHCnAiEVrY0dyBhUIuacGBfm40eBWEzr22qgI vhfA== X-Gm-Message-State: ALoCoQkj2LFbr72MPqO/+Uv3o6T+R2GmV0enm9xzSe61+j26tlyYMhxQ/TmLqLE8lzu0Q7trtb6Z X-Received: by 10.14.88.131 with SMTP id a3mr6993989eef.64.1391809879820; Fri, 07 Feb 2014 13:51:19 -0800 (PST) Received: from ams-townsley-8916.cisco.com (173-38-208-169.cisco.com. [173.38.208.169]) by mx.google.com with ESMTPSA id v6sm1051914eef.2.2014.02.07.13.51.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 07 Feb 2014 13:51:15 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: <52F538A4.6090004@gmail.com> Date: Fri, 7 Feb 2014 22:51:14 +0100 Content-Transfer-Encoding: 7bit Message-Id: <96576340-13A0-43A0-94C5-DE1E30656E06@townsley.net> References: <2922CC94-540D-4215-899B-4722BD1C5EBC@employees.org> <52EF90BD.4070701@gmail.com> <18C8BE29C547CC4DBBCF3C4F0B8EC1780608ED@wds-exc1.okna.nominet.org.uk> <8B52F0C3-EB5A-48D1-9596-52302F6A4A3C@darou.fr> <8FA52BBD-9A61-4795-9BA3-AB8B0A63EB98@fugue.com> <29DCB6B2-B428-4B45-8796-ACB09E40376A@fugue.com> <26945.1391525921@sandelman.ca> <2BE96E0A-D9A7-492F-B07F-9C83767C6F0D@darou.fr> <445.1391555635@sandelman.ca> <52F1A6D6.8020801@gmail.com> <52F22AF1.6060300@gmail.com> <52F28DD4.8000104@gmail.com> <51637E3C-7BA6-4AB2-96C3-1B23C6F15C9D@townsley.net> <52F538A4.6090004@gmail .com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1283) Cc: "homenet@ietf.org" , Lorenzo Colitti , Mikael Abrahamsson Subject: Re: [homenet] DSCP X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 21:51:22 -0000 On Feb 7, 2014, at 8:48 PM, Brian E Carpenter wrote: > On 08/02/2014 00:20, Mikael Abrahamsson wrote: >> On Fri, 7 Feb 2014, Lorenzo Colitti wrote: >> >>>> Absolutely, but it means resetting DSCP, thus breaking QoS in other >>>> parts >>>> of the packet path. >>> >>> Well to be more precise, it means making sure DSCP is a value that the >>> customer is allowed to use (or rewriting it). Just like you have to make >>> sure that the packet's source address is a value that the customer is >>> allowed to use (or dropping the packet). No? >> >> Correct. > > Yes. There's nothing we've discussed in this thread that is different > from the diffserv architecture (RFC 2475). Diffserv works within > a single administrative domain (possibly split up using tunnels). > There are some efforts towards inter-provider diffserv in TSVWG > (RFC 4594, RFC 5127, draft-geib-tsvwg-diffserv-intercon). Great, happy to see everyone finally at some level of violent agreement then! - Mark > > Brian > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From v6ops@globis.net Mon Feb 10 08:53:06 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 530EA1A06F5 for ; Mon, 10 Feb 2014 08:53:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J2Lurtyqwxch for ; Mon, 10 Feb 2014 08:53:04 -0800 (PST) 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 4D2E41A06F1 for ; Mon, 10 Feb 2014 08:53:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 1D68D870074; Mon, 10 Feb 2014 17:52:59 +0100 (CET) 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 zyKkmMukpFIl; Mon, 10 Feb 2014 17:52:59 +0100 (CET) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 05877870073; Mon, 10 Feb 2014 17:52:59 +0100 (CET) Message-ID: <52F903EB.8060508@globis.net> Date: Mon, 10 Feb 2014 17:52:59 +0100 From: Ray Hunter User-Agent: Postbox 3.0.9 (Macintosh/20140129) MIME-Version: 1.0 To: Lorenzo Colitti References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ole Troan , "homenet@ietf.org Group" Subject: Re: [homenet] Homenet protocol decisions X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 16:53:06 -0000 Lorenzo Colitti wrote: > On Thu, Jan 30, 2014 at 2:48 AM, Ole Troan > wrote: > > We need to decide, if we want prefix assignment and distribution > of other configuration information integrated in a routing protocol. > > > I think the two should be in the same protocol, because routing and > addressing are tightly coupled. Fundamentally, there is no point in > configuring an address on a host if the homenet doesn't have > reachability to it - because you can't use that address to talk to > anyone else in the homenet. > > If the routing protocol and the prefix distribution protocol are > separate, then they can end up with different ideas on what prefix is > on a given link. That will lead to blackholing. +1 I don't see how you're going to avoid tight coupling and still keep things stable when/if provider links and internal links flap. IMHO there's got to be some form of fate sharing to avoid every single app having to implement a version of happy eyeballs. -- Regards, RayH From Ray.Bellis@nominet.org.uk Tue Feb 11 04:13:30 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 174ED1A0808 for ; Tue, 11 Feb 2014 04:13:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.848 X-Spam-Level: X-Spam-Status: No, score=-4.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNRkkDp1IYaS for ; Tue, 11 Feb 2014 04:13:28 -0800 (PST) Received: from mx1.nominet.org.uk (mail.nominet.org.uk [213.248.242.48]) by ietfa.amsl.com (Postfix) with ESMTP id A29401A0800 for ; Tue, 11 Feb 2014 04:13:26 -0800 (PST) DomainKey-Signature: s=main2.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:X-IPAS-Result:Received:Received:From:To: Subject:Thread-Topic:Thread-Index:Date:Message-ID: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:x-originating-ip:Content-Type: Content-ID:Content-Transfer-Encoding:MIME-Version; b=EAYnW0Ea+0UDzUgxqhAOVb8JfDozOmALcKFk4jgsYq3Lj9PXwTQHuMBK ONNSMf+9oXtCQnbUvu/PR+0kkng45XGkE4BM6RnUP5ttJ9UuQ+vyCBad5 CE5rD7aRbHpQqhJxIpV5MqtX+4ivrM55M57mTvtLhTI67omSRK5xAiJHw VohQjhqpWpVFSreEX2XlQ/Aq8BqkmemWhZYx7Qku1SFWwE41xj0HHhRLv WEJi26Isu1nMY5vpCeh+aeEYoBciE; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=@nominet.org.uk; q=dns/txt; s=main2.dkim.nominet.selector; t=1392120807; x=1423656807; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=skIMl/VxSDLx5W3z7sj5ug+OuT64eGW1xlimaTu1N7E=; b=UmY08AYXsvAVFnKrGXkoM8+lM8aqJxDOZmtGM3Z0RvGnXpJ6G7DECRo0 KaQYLC12A1BsMX4S8SvenM+dJ0LKNJxd7V2dnJqmTaoaA4Altq44ZsTf7 Tm36+7UCWlBMZhA/SRZ/cnu3Boa8hMJoaNFYcAYbmg/dOSjCQR2rO4M+k gF+lOHdpT6Yxh+tXSwv2458IPKSKQrPHgOXhfB+n+FoSjvbo+D897eZy3 XDTsA7aZOwjObbpeP5gCn3Er9EivN; X-IronPort-AV: E=Sophos;i="4.95,825,1384300800"; d="scan'208";a="7542222" X-IPAS-Result: AgkFACwT+lLV+MWQ/2dsb2JhbABZgmshgQ++ZYEQFnSCJwU6GTgBKhRCJwQbh34DmT6vNxeOSINcgRQEqkqDLYIq Received: from wds-exc1.okna.nominet.org.uk ([213.248.197.144]) by mx1.nominet.org.uk with ESMTP; 11 Feb 2014 12:13:25 +0000 Received: from WDS-EXC2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4]) by wds-exc1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f%17]) with mapi id 14.02.0318.004; Tue, 11 Feb 2014 12:13:25 +0000 From: Ray Bellis To: "homenet@ietf.org Group" Thread-Topic: Submission cutoff Thread-Index: AQHPJyKpowdiwWUYnUyKaybQQAnqZw== Date: Tue, 11 Feb 2014 12:13:24 +0000 Message-ID: <18C8BE29C547CC4DBBCF3C4F0B8EC178079DFF@wds-exc2.okna.nominet.org.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.1] Content-Type: text/plain; charset="us-ascii" Content-ID: <01FFB1F2582B164ABCBD43094333D9FB@okna.nominet.org.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [homenet] Submission cutoff X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 12:13:30 -0000 The submission cutoff for IETF 89 is *this Friday* 14th Feb at 23:59 UTC. Please get any new drafts in ASAP! thanks, Ray From rja.lists@gmail.com Wed Feb 12 12:42:06 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 908A41A0450 for ; Wed, 12 Feb 2014 12:42:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vW5JbD6Kr2FS for ; Wed, 12 Feb 2014 12:42:04 -0800 (PST) Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [IPv6:2607:f8b0:400d:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id E64981A066B for ; Wed, 12 Feb 2014 12:42:03 -0800 (PST) Received: by mail-qc0-f175.google.com with SMTP id x13so16145952qcv.20 for ; Wed, 12 Feb 2014 12:42:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version; bh=ioJz/ELZF6sLkRUhylEPC4370m59Lxy6Kf6Wp4zmX/A=; b=EjLJcJXjk4ZAncu4qHIxMn2cUszlVAYU6I16aoCuQ7lrGiHTe5vnm1jcJH2adz36Ic owNsbUoFU1JNHKRnhZMxmonNiGD8rLuxzwRPQ0AggnfjuxuKg3VY8H+BBHq5sJml2w7x bX5dQh/n2IkSQWzFdxV/qGGTjtY6giHeSNjyoV4//6AT0y/F6xjfbPmX7nm8kxhTrXrM uTNbyuqbzmtmKNiQLEUVqZCFMLHz+/Uhjdq1TWHGlZROnepyg/zADyEvtaV826w/SLaK EZuInDFw4/moylXvtZdLyZzvZ7vcWN5XTJtnS+KohzZ4KJTi2bjr7Y3LnEtOUEasKb6U 3tbA== X-Received: by 10.224.62.14 with SMTP id v14mr32788021qah.79.1392237722831; Wed, 12 Feb 2014 12:42:02 -0800 (PST) Received: from [10.30.20.14] (pool-173-79-6-58.washdc.fios.verizon.net. [173.79.6.58]) by mx.google.com with ESMTPSA id r40sm21662553qga.23.2014.02.12.12.42.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 12 Feb 2014 12:42:02 -0800 (PST) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 12 Feb 2014 15:42:01 -0500 Message-Id: <14D2CA66-0038-42C5-9B05-09A402AFC321@gmail.com> To: homenet@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: [homenet] Prefix semantics (not) [was: DHCP PD] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 20:42:06 -0000 On 6th February 2014, Brian Carpenter said, in part: > We designed diffserv for this purpose and it works well > and is quite widely used in corporate networks. Yes. Purely as an example, one of my clients is using the IP ToS/DSCP byte to distinguish between various kinds of traffic inside their large enterprise network. It works well for them. I also will note that some existing low-cost "consumer" router/switch products for sale off-the-shelf (in multiple countries on various continents) already include support for DiffServ/IP-ToS. As near as I can tell, this has been true for at least 5 years now. So some folks' residential in-home networks might already support DiffServ/IP-ToS without any home user configuration needed. > Wasting prefixes to distinguish traffic types is an incredibly bad idea. I could not agree more with that sentence just above. Wasting prefixes is a terribly dangerous idea. The IETF really OUGHT NOT (emphasis intentional) endorse, support, or approve of any form of prefix misuse. Yours, Ran From mglt.ietf@gmail.com Thu Feb 13 08:38:19 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B128B1A0361 for ; Thu, 13 Feb 2014 08:38:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lwAhUqT5AOz1 for ; Thu, 13 Feb 2014 08:38:17 -0800 (PST) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 08A7F1A0360 for ; Thu, 13 Feb 2014 08:37:55 -0800 (PST) Received: by mail-we0-f178.google.com with SMTP id q59so7807882wes.9 for ; Thu, 13 Feb 2014 08:37:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=JyhkmVyVhBqNFM0r6Jxv4OYvSXh1svzEBwFkB2jr8Lc=; b=Uu4EiOqBp5/ewgR7SMd60pFbXlMEG3eDSrxmbNSO4dIfAP4ajk2ahMQGDvOGb9PeLF ihK5O7cln5R36mPHXleplBAYhOfyBjUHRH0rQ/cBOCDuMHbiAfPAD8/entnwB1k3/bKs DHH2n3uKc8LDPYp3GZJ7E36AuMxONMZov1vuX3XBgaWcDEGLtvKMflRHWh7liQUcE4Yq SNWiMtGdnyE19FaSTUc+JfpIgcdnI4wL+LcT7WSMVwhZkqfbenECbSAB2TJS+dDYlpzJ z9E36x+cE9ENYHComW/8Yrl8Zqnk2YQgDMyVru3qCdojzSOhQYqYT3C+e8ngcjo2guP+ LVgw== MIME-Version: 1.0 X-Received: by 10.180.13.33 with SMTP id e1mr7334837wic.38.1392309474279; Thu, 13 Feb 2014 08:37:54 -0800 (PST) Received: by 10.194.171.129 with HTTP; Thu, 13 Feb 2014 08:37:54 -0800 (PST) Date: Thu, 13 Feb 2014 17:37:54 +0100 Message-ID: From: Daniel Migault To: "homenet@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: [homenet] draft-mglt-homenet-naming-architecture-dhc-options-01 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 16:38:19 -0000 Hi, Please find the new version of the draft draft-mglt-homenet-naming-architecture-dhc-options-01. It defines DHCP Options to configure the Homenet naming architecture. Feel free to comment! BR, Daniel A new version of I-D, draft-mglt-homenet-naming-architecture-dhc-options-01.txt has been successfully submitted by Daniel Migault and posted to the IETF repository. Name: draft-mglt-homenet-naming-architecture-dhc-options Revision: 01 Title: DHCP Options for Homenet Naming Architecture Document date: 2014-02-13 Group: Individual Submission Pages: 18 URL: http://www.ietf.org/internet-drafts/draft-mglt-homenet-naming-architecture-dhc-options-01.txt Status: https://datatracker.ietf.org/doc/draft-mglt-homenet-naming-architecture-dhc-options/ Htmlized: http://tools.ietf.org/html/draft-mglt-homenet-naming-architecture-dhc-options-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-mglt-homenet-naming-architecture-dhc-options-01 Abstract: The home network naming architecture requires a complex naming configuration on the CPE. This configuration MAY not be handled easily by the average end user. Furthermore, such misconfiguration MAY result in making home network unreachable. This document proposes a DHCP options that provide the CPE all necessary parameters to set up the home network naming architecture. First, this DHCP options provide automatic configuration and avoid most end users' misconfiguration. Most average end users may not require specific configuration, and their ISP default configuration MAY fully address their needs. In that case, the naming homenet architecture configuration will be completely transparent to the end users. Then, saving naming configuration outside the CPE, makes it resilient to change of CPE or CPE upgrades. Such configuration may also be configured by the end user, via the customer area of their ISP. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 From nobody Thu Feb 13 09:41:51 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17FA51A0384 for ; Thu, 13 Feb 2014 09:41:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aDRBd25dtBSE for ; Thu, 13 Feb 2014 09:41:45 -0800 (PST) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by ietfa.amsl.com (Postfix) with ESMTP id 6FA071A02CD for ; Thu, 13 Feb 2014 09:41:43 -0800 (PST) Received: by mail-pa0-f54.google.com with SMTP id fa1so11080468pad.13 for ; Thu, 13 Feb 2014 09:41:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:message-id:mime-version :subject:date:references:to:in-reply-to; bh=6LdPAnXr8Cv+LTc78D14ROpo9rj4uPbWnf6y687srx0=; b=jrKS76b0kBzD8i4BpRxd1fMXtSGhGIUHmuDV2u3/nK8d2BiJ+dV5MW2+5TMLYvN43V +kg1pL3g0wJ3bSs3W0JJLng8JKKKjf6u599m6ogccvSLuebfJLP33gyuIM6pxV+gYN97 L/+9+20oWsr953AQVcaYtKJnquT+2NWuzBrcKkL4WyLq++Ah8cksT9Xl8E1AfE0QvaeG A8ObdRKjv6+/Ze/Glg65DlBqvRPv/cdttwFERTRcca4BhqUIw26adMBFFUpEKOKIDQ0B 3LVofiqJov8dqocs1lVEvabfmYdyPm1CxOM4HMxtzJInnsfzkFlaM1xx3kE8QSm3rZ38 MP0Q== X-Gm-Message-State: ALoCoQnJAq512FtPL/xnl0NTwhnAEsC08aP4W7Z0HnBVmu95Ezj2PT1ul8z6qLb5OvfhCy9eo7iU X-Received: by 10.68.202.225 with SMTP id kl1mr3314519pbc.54.1392313302275; Thu, 13 Feb 2014 09:41:42 -0800 (PST) Received: from sjc-vpn7-1914.cisco.com (128-107-239-235.cisco.com. [128.107.239.235]) by mx.google.com with ESMTPSA id qh2sm19756522pab.13.2014.02.13.09.41.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Feb 2014 09:41:39 -0800 (PST) From: Mark Townsley Content-Type: multipart/alternative; boundary="Apple-Mail=_B7100CA9-4DC7-4D04-931B-1998DE72D011" Message-Id: <6BF5B681-446C-4BCA-9B53-A05A9D4A9E38@townsley.net> Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Date: Thu, 13 Feb 2014 09:41:36 -0800 References: <58809B4D-CCE4-4DAC-9A1A-DD475584E65B@iki.fi> To: "homenet@ietf.org Group" In-Reply-To: <58809B4D-CCE4-4DAC-9A1A-DD475584E65B@iki.fi> X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/BrOmYfURp8JEq7jgcjKrh9PrdAk Subject: [homenet] HNCP X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 17:41:49 -0000 --Apple-Mail=_B7100CA9-4DC7-4D04-931B-1998DE72D011 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 All, In case anyone missed it, Markus and Pierre posted drafts and a pointer = to an implementation describing the Home Net Control Protocol.=20 I'd like to provide some additional background, hat off. The work Markus, Stephen and Pierre have been doing is funded by a = "Cisco Technology Fund" grant. The purpose of this grant has been to = deliver technology backed by open source code that will be adopted by a = community willing to maintain it, with the ultimate goal of that = technology making its way into commercial product (for this to matter, = it needs to make it into far more than Cisco product). During its first = phase of operation, the main focus was on work originally started by = Jari Arkko, Acee Lindem, and Benjamin Paterson in OSPF by fleshing this = out in code and spec. Much was learned, and you may have seen some of = the results at various bits-n-bytes and in draft updates (or the Markus' = github if you were watching). The second phase, which began after the = Berlin IETF, has been to take what was learned in the first phase and = focus on: - upstreaming the technology into an open source project (in this case, = OpenWRT) - modularity and adaptability to other routing protocols (e.g., ISIS) - best-effort capabilities in simple topologies in case one common = routing protocol support was not available - integration with draft-behringer-homenet-trust-bootstrap and = draft-kline-default-perimeter The result after several months of heads-down effort is contained in the = drafts below. The document from pfister is an evolution of the IPv6 = prefix assignment work started by Jari, but in its own document such = that it can be referenced by to OSPF, ISIS, HNCP, etc. The two from = stenberg describe HNCP, as well as a general way to support Stuart's = work in draft-cheshire-mdnsext-hybrid in a zeroconf mannter when the = list of routers in a site is known (as HNCP does, or any link-state = routing protocol should).=20 Personally, I was very skeptical when the team let me know that the = result of their analysis led them to the need to create HNCP. If nothing = else, between the OSPF work done in Phase one, and the HNCP work in = Phase two, these are two concrete examples in draft and code form for = the WG to examine to help decide the first question at the top of Ole's = flowchart posted here earlier. For those with no time to read the drafts, here's my one paragraph = synopsis of what HNCP does: HNCP uses the Trickle (RFC6206) algorithm to trigger when basic = configuration state for the homenet is out of sync on any router. = Essentially, a hash (or signature if security is present) over an = ordered list of the known homenet nodes and attributes necessary to keep = the homenet alive is handed over to Trickle. Trickle worries only about = that hash value, and whether all nodes agree that the value is the same. = When they don't agree, HNCP sends update messages between nodes until = Trickle is happy again. The HNCP document also defines some specifics = used in the OpenWRT implementation for border detection (based on = draft-kline-homenet-default-perimeter), some hooks for integration with = Behringer's trust bootstrapping (not 100% finished though), IPv4 and = IPv6 prefix distribution, and an auto-negotiation mechanism depending on = what type of routing protocol support is available. In the event no = common routing protocol is available, HNCP defines a "fallback" mode = that at least gets packets out the right interface and avoids loops, = even if the path is not ideal, has no metrics, etc.=20 This is all pretty close to what the team set out to achieve with the 4 = bullets above as constraints and guidelines. Of this I can't help to be = impressed. It came with a new protocol though, which shouldn't be taken = lightly, but indeed might be necessary. I look forward to what the WG = ultimately decides here.=20 Finally, if you want to follow some of the work being done by Markus, = Stephen, Pierre, et. al. without necessarily logging into a github to do = it, you can poke around here: http://www.homewrt.org (it may be a tad = behind the latest-greatest though).=20 Hat back on now=85 Tim, Ray and I are working with the ADs to get the = homenet-arch doc through the system. According to Tim, all DISCUSS = points have been worked out on email with ADs weeks if not months ago, = and the results are in -12 which has been posted. We're back to prodding = ADs for time and mental cache reloading of their issues for them to = clear. Once that is finished, the WG will finally be at a point that it = can "officially" work on solutions. Now, as Markus asked, "Discuss"! :-) - Mark Markus Stenberg (and Pierre Pfister) wrote: > Drafts: > http://tools.ietf.org/html/draft-stenberg-homenet-hncp-00 > = http://tools.ietf.org/html/draft-stenberg-homenet-dnssd-hybrid-proxy-zeroc= onf-00 > = http://tools.ietf.org/html/draft-pfister-homenet-prefix-assignment-00=20 >=20 > Experimental partial implementation: > https://github.com/sbyx/hnetd/ >=20 > Discuss. >=20 > Cheers, >=20 > -Markus > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet --Apple-Mail=_B7100CA9-4DC7-4D04-931B-1998DE72D011 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

- upstreaming the = technology into an open source project (in this case, = OpenWRT)
- modularity and adaptability to other routing = protocols (e.g., ISIS)
- best-effort capabilities in simple = topologies in case one common routing protocol support was not = available
- integration = with draft-behringer-homenet-trust-bootstrap = and draft-kline-default-perimeter

The = result after several months of heads-down effort is contained in the = drafts below. The document from pfister is an evolution of the IPv6 = prefix assignment work started by Jari, but in its own document such = that it can be referenced by to OSPF, ISIS, HNCP, etc. The two from = stenberg describe HNCP, as well as a general way to support Stuart's = work in draft-cheshire-mdnsext-hybrid in a zeroconf mannter when the = list of routers in a site is known (as HNCP does, or any link-state = routing protocol should). 

Personally, I = was very skeptical when the team let me know that the result of their = analysis led them to the need to create HNCP. If nothing else, = between the OSPF work done in Phase one, and the HNCP work in Phase two, = these are two concrete examples in draft and code form for the WG to = examine to help decide the first question at the top of Ole's flowchart = posted here earlier.

For those with no time to = read the drafts, here's my one paragraph synopsis of what HNCP = does:

HNCP uses the Trickle (RFC6206) algorithm = to trigger when basic configuration state for the homenet is out of sync = on any router. Essentially, a hash (or signature if security is = present) over an ordered list of the known homenet nodes and attributes = necessary to keep the homenet alive is handed over to Trickle. Trickle = worries only about that hash value, and whether all nodes agree that the = value is the same. When they don't agree, HNCP sends update messages = between nodes until Trickle is happy again. The HNCP document also = defines some specifics used in the OpenWRT implementation for border = detection (based on draft-kline-homenet-default-perimeter), some hooks = for integration with Behringer's trust bootstrapping (not 100% finished = though), IPv4 and IPv6 prefix distribution, and an auto-negotiation = mechanism depending on what type of routing protocol support is = available. In the event no common routing protocol is available, HNCP = defines a "fallback" mode that at least gets packets out the right = interface and avoids loops, even if the path is not ideal, has no = metrics, etc. 

This is all pretty close to = what the team set out to achieve with the 4 bullets above as constraints = and guidelines. Of this I can't help to be impressed. It came with a new = protocol though, which shouldn't be taken lightly, but indeed might be = necessary. I look forward to what the WG ultimately decides = here. 

Finally, if you want to follow some = of the work being done by Markus, Stephen, Pierre, et. al. without = necessarily logging into a github to do it, you can poke around = here: http://www.homewrt.org = (it may be a tad behind the latest-greatest = though). 

Hat back on now=85 Tim, Ray and = I are working with the ADs to get the homenet-arch doc through the = system. According to Tim, all DISCUSS points have been worked out on = email with ADs weeks if not months ago, and the results are in -12 which = has been posted. We're back to prodding ADs for time and mental cache = reloading of their issues for them to clear. Once that is finished, the = WG will finally be at a point that it can "officially" work on = solutions.

Now, as Markus asked, "Discuss"! = :-)

- = Mark


Markus Stenberg <markus.stenberg@iki.fi> = (and Pierre Pfister) wrote:

Drafts:
=   http://= tools.ietf.org/html/draft-stenberg-homenet-hncp-00
=   http://tools.ietf.org/html/draft-stenberg-homenet-dnssd-hy= brid-proxy-zeroconf-00
  http://tools.ietf.org/html/draft-pfister-homenet-prefix-assignment-00=  

Experimental = partial implementation:
  https://github.com/sbyx/hnetd/=

Discuss.

Cheers,

-Markus
________________________= _______________________
homenet mailing list
homenet@ietf.org
https://www.ietf.= org/mailman/listinfo/homenet

= --Apple-Mail=_B7100CA9-4DC7-4D04-931B-1998DE72D011-- From nobody Thu Feb 13 10:22:43 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B8A91A03B1 for ; Thu, 13 Feb 2014 10:22:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n5lhcnzC0JhW for ; Thu, 13 Feb 2014 10:22:35 -0800 (PST) Received: from mail-pb0-f49.google.com (mail-pb0-f49.google.com [209.85.160.49]) by ietfa.amsl.com (Postfix) with ESMTP id 564FF1A03D9 for ; Thu, 13 Feb 2014 10:22:35 -0800 (PST) Received: by mail-pb0-f49.google.com with SMTP id up15so11056173pbc.8 for ; Thu, 13 Feb 2014 10:22:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:references:from:content-type:in-reply-to :message-id:date:to:content-transfer-encoding:mime-version; bh=461RBmXnlPA/CVlxp3yybeTCkXBPAYMdcfAvwJ+qsw4=; b=T/bl7kMuXihl/lq13XyhEw+ao4lFANrihegqTvozzJSsY4CYHkd9llJinsGqrbTFun O3WG3b4CqqAUZXYYEYqF6JuNgbOGZpdKG2A0bgh4LPwluIrePVPlrzgXgVCP1n02TQIj rTIYRz9tDz1XtCayTfMSgCzxIHGC/vMHwA8tJd7j0wlWcmrlQIzUceGg5QqVPsdEP+gX yFtfQteq7+ur4G8SNhga99Ai2xVoU9yWrQ4+ghlYr24bsQi5tASqfQbr/fN9uVJrRude S1Algf4Okuaj0AIc8cvDiu1TIEWCzOu2aov1pC9Y7Ak4NGbGZLWmlPxmhXvSbfmpUjYF lXVQ== X-Gm-Message-State: ALoCoQntJNmZkXlb3pkIA0kltQSQw3nzFbS5sNT3bjj+MMhUiU0IfQpbZH0gbHsmo81LwY8kUQyY X-Received: by 10.68.134.98 with SMTP id pj2mr3459928pbb.110.1392315754238; Thu, 13 Feb 2014 10:22:34 -0800 (PST) Received: from [10.132.81.207] ([64.124.208.80]) by mx.google.com with ESMTPSA id ja8sm8884234pbd.3.2014.02.13.10.22.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Feb 2014 10:22:32 -0800 (PST) References: <58809B4D-CCE4-4DAC-9A1A-DD475584E65B@iki.fi> <6BF5B681-446C-4BCA-9B53-A05A9D4A9E38@townsley.net> From: "Townsley.net" Content-Type: text/plain; charset=us-ascii X-Mailer: iPhone Mail (10B350) In-Reply-To: <6BF5B681-446C-4BCA-9B53-A05A9D4A9E38@townsley.net> Message-Id: Date: Thu, 13 Feb 2014 10:22:30 -0800 To: "homenet@ietf.org Group" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/YGjFmOF9zyY61KYjgsUYZU4U5dk Subject: Re: [homenet] HNCP X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 18:22:38 -0000 > Personally, I was very skeptical when the team let me know that the result= of their analysis led them to the need to create HNCP.=20 I forgot to add that, after looking deeper into what had actually been done= , I warmed up to the idea greatly. That's just me though...I look forward to= what others think here.=20 - Mark From nobody Thu Feb 13 10:40:01 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF8451A03B3 for ; Thu, 13 Feb 2014 10:39:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnXDXGG-nxzK for ; Thu, 13 Feb 2014 10:39:56 -0800 (PST) Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [IPv6:2607:f8b0:400d:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE591A03AB for ; Thu, 13 Feb 2014 10:39:56 -0800 (PST) Received: by mail-qc0-f175.google.com with SMTP id x13so18259445qcv.20 for ; Thu, 13 Feb 2014 10:39:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=DmTHhxD/cANU6h4AFeyJdETl7aXTUbqn/hojrYRUyPg=; b=zJa4DBjpxQsYlpWBVvO9czcxEDwYP1eHL+Et7moK/b+8ltYMBwzlrL6RPEM4mg/giA gCy8iWye3ftZrydwZdh4FloOJRkfm7m2MF2iVXcDbj6yzySYQ5sbF8DGhfq89KU7+ApG LcG3I3QVL8ELEfc2vKY2mXht4ble0JTGmnkeTmG2q0DJh7p159+cmhgVrqBY6x0OIQ3h 6yKAOQ6WCL1cd4yZ7YwtDIhjUxATVWF5IzhO2+8H3DVGYBFcaCDnXiphfxX6eKme4EMI asA+hZZ7JvcTjzMYdAEKhUj1AvUrhRITW1tEGTs9wZfa3KatlBmxMcudxrFkCMPx9hhO 5Lyg== MIME-Version: 1.0 X-Received: by 10.140.49.9 with SMTP id p9mr4861480qga.75.1392316795003; Thu, 13 Feb 2014 10:39:55 -0800 (PST) Received: by 10.224.27.133 with HTTP; Thu, 13 Feb 2014 10:39:54 -0800 (PST) In-Reply-To: References: <58809B4D-CCE4-4DAC-9A1A-DD475584E65B@iki.fi> <6BF5B681-446C-4BCA-9B53-A05A9D4A9E38@townsley.net> Date: Thu, 13 Feb 2014 13:39:54 -0500 Message-ID: From: Dave Taht To: "Townsley.net" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/vqHKKMZDC4a2vwXoJQSgdKBDOYk Cc: "homenet@ietf.org Group" Subject: Re: [homenet] HNCP X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 18:39:58 -0000 On Thu, Feb 13, 2014 at 1:22 PM, Townsley.net wrote: > > >> Personally, I was very skeptical when the team let me know that the resu= lt of their analysis led them to the need to create HNCP. I am delighted to see the work. Unfortunately I haven't had time to review the draft fully or much of the code as yet; it was quite the surprise to see it! It was wonderful to see the git clone... What I looked over appeared to be a massive step forward that can break the logjam here, evolve rapidly, and be deployed rapidly. I'm not sure if it's an AHCP replacement (can I get a /128 somewhere a few hops away?) I am glad there is room in the protocol for other routing protocols. Have the RPL (IoT) folk had a gander? In the 5 minutes I had with it, I felt the crypto architecture needed fleshing out, and I wondered if there was a notion of "distance". (to explain that, take a network with two multihomed egress points and dozens of routers in between. Fully distributing both sets of prefixes in an entirely flat fashion might not be feasible or necessary.) Unlike some perhaps I'd like to solve at least a few ipv4 related problems, notably nat detection and saner rfc1918 prefix distribution, but I imagine that will be a rathole. Lastly: Trickle is very cool. > I forgot to add that, after looking deeper into what had actually been d= one, I warmed up to the idea greatly. That's just me though...I look forwar= d to what others think here. > > - Mark > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html From nobody Fri Feb 14 08:45:21 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1CD21A025A for ; Fri, 14 Feb 2014 08:45:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wLlw67LhxZDg for ; Fri, 14 Feb 2014 08:45:16 -0800 (PST) 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 EF2BD1A01F3 for ; Fri, 14 Feb 2014 08:45:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 6147E870078; Fri, 14 Feb 2014 17:45:05 +0100 (CET) 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 6H33bhr1-S32; Fri, 14 Feb 2014 17:45:05 +0100 (CET) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 32027870046; Fri, 14 Feb 2014 17:45:05 +0100 (CET) Message-ID: <52FE480F.3030801@globis.net> Date: Fri, 14 Feb 2014 17:45:03 +0100 From: Ray Hunter User-Agent: Postbox 3.0.9 (Macintosh/20140129) MIME-Version: 1.0 To: Mark Townsley , cyrus@openwrt.org, markus.stenberg@iki.fi References: <58809B4D-CCE4-4DAC-9A1A-DD475584E65B@iki.fi> <6BF5B681-446C-4BCA-9B53-A05A9D4A9E38@townsley.net> In-Reply-To: <6BF5B681-446C-4BCA-9B53-A05A9D4A9E38@townsley.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/Vs6Ki2K1ynUD9GPRdqHrNHXDHYk Cc: "homenet@ietf.org Group" Subject: Re: [homenet] HNCP X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 16:45:18 -0000 Mark Townsley wrote: > > All, > > In case anyone missed it, Markus and Pierre posted drafts and a > pointer to an implementation describing the Home Net Control Protocol. > Running code is very welcome. > I'd like to provide some additional background, hat off. > > The work Markus, Stephen and Pierre have been doing is funded by a > "Cisco Technology Fund" grant. The purpose of this grant has been to > deliver technology backed by open source code that will be adopted by > a community willing to maintain it, with the ultimate goal of that > technology making its way into commercial product (for this to matter, > it needs to make it into far more than Cisco product). During its > first phase of operation, the main focus was on work originally > started by Jari Arkko, Acee Lindem, and Benjamin Paterson in OSPF by > fleshing this out in code and spec. Much was learned, and you may have > seen some of the results at various bits-n-bytes and in draft updates > (or the Markus' github if you were watching). The second phase, which > began after the Berlin IETF, has been to take what was learned in the > first phase and focus on: > > - upstreaming the technology into an open source project (in this > case, OpenWRT) > - modularity and adaptability to other routing protocols (e.g., ISIS) > - best-effort capabilities in simple topologies in case one common > routing protocol support was not available > - integration with draft-behringer-homenet-trust-bootstrap > and draft-kline-default-perimeter > > The result after several months of heads-down effort is contained in > the drafts below. The document from pfister is an evolution of the > IPv6 prefix assignment work started by Jari, but in its own document > such that it can be referenced by to OSPF, ISIS, HNCP, etc. The two > from stenberg describe HNCP, as well as a general way to support > Stuart's work in draft-cheshire-mdnsext-hybrid in a zeroconf mannter > when the list of routers in a site is known (as HNCP does, or any > link-state routing protocol should). > > Personally, I was very skeptical when the team let me know that the > result of their analysis led them to the need to create HNCP. If > nothing else, between the OSPF work done in Phase one, and the HNCP > work in Phase two, these are two concrete examples in draft and code > form for the WG to examine to help decide the first question at the > top of Ole's flowchart posted here earlier. > > For those with no time to read the drafts, here's my one paragraph > synopsis of what HNCP does: > > HNCP uses the Trickle (RFC6206) algorithm to trigger when basic > configuration state for the homenet is out of sync on any router. > Essentially, a hash (or signature if security is present) over an > ordered list of the known homenet nodes and attributes necessary to > keep the homenet alive is handed over to Trickle. Trickle worries only > about that hash value, and whether all nodes agree that the value is > the same. When they don't agree, HNCP sends update messages between > nodes until Trickle is happy again. The HNCP document also defines > some specifics used in the OpenWRT implementation for border detection > (based on draft-kline-homenet-default-perimeter), some hooks for > integration with Behringer's trust bootstrapping (not 100% finished > though), IPv4 and IPv6 prefix distribution, and an auto-negotiation > mechanism depending on what type of routing protocol support is > available. In the event no common routing protocol is available, HNCP > defines a "fallback" mode that at least gets packets out the right > interface and avoids loops, even if the path is not ideal, has no > metrics, etc. > > This is all pretty close to what the team set out to achieve with the > 4 bullets above as constraints and guidelines. Of this I can't help to > be impressed. It came with a new protocol though, which shouldn't be > taken lightly, but indeed might be necessary. I look forward to what > the WG ultimately decides here. > > Finally, if you want to follow some of the work being done by Markus, > Stephen, Pierre, et. al. without necessarily logging into a github to > do it, you can poke around here: http://www.homewrt.org (it may be a > tad behind the latest-greatest though). > > Hat back on now… Tim, Ray and I are working with the ADs to get the > homenet-arch doc through the system. According to Tim, all DISCUSS > points have been worked out on email with ADs weeks if not months ago, > and the results are in -12 which has been posted. We're back to > prodding ADs for time and mental cache reloading of their issues for > them to clear. Once that is finished, the WG will finally be at a > point that it can "officially" work on solutions. > > Now, as Markus asked, "Discuss"! :-) > > - Mark > > > Markus Stenberg > (and Pierre Pfister) wrote: > >> Drafts: >> http://tools.ietf.org/html/draft-stenberg-homenet-hncp-00 I have read this draft. Quotes below marked > are from the draft.... > > Is there a case for non-link-local unicast? Not IMHO. That could be extremely unstable and introduce circular dependencies on routing. My comments on the obvious questions. > > Q: Why not use TCP? > > A: It doesn't address the node discovery problem. It also leads to > N*(N-1)/2 connections when N nodes share a link, which is awkward. > Agreed. > > Q: Why effectively build a link state routing protocol without > routing? > > > > A: It felt like a good idea at the time. It does not require > periodic flooding except for very minimal Trickle-based per-link > state maintenance (potentially also neighbor reachability checks if > so desired). > I can understand that you might need to produce a separate Homenet configuration protocol, especially during development, just so you can play with it a bit. Running code is welcome. But what is fundamentally different in this protocol compared to if the TLV flooding was folded back into the IGP implementation? Link state IGPs come with tried and tested flooding mechanisms. I'm not yet convinced dynamic negotiation of routing protocol is a desirable feature. > > Q: Why not multicast-only? > > A: It would require defining application level fragmentation scheme. > Hopefully the data amounts used will stay small so we just trust > unicast UDP to handle 'big enough' packets to contain single node's > TLV data. On some link layers unicast is also much more reliable > than multicast, especially for large packets. > The choice of multicast or unicast should be made based on the underlying local link technology. There are links where multicast is cheap and desirable (to reach many neighbors simultaneously) and there are links where unicast is desirable, to avoid waking non-neighbors or where multicast is not supported. > > Q: Why so long IDs? Why real hash even in insecure mode? > > A: Scalability of protocol isn't really affected by using real > (=cryptographic) hash function. > > > Q: Why trust IPv6 fragmentation in unicast case? Why not do L7 > fragmentation? > > A: Because it will be there for a while at least. And while PMTU et > al may be problems on open internet, in a home network environment > UDP fragmentation should NOT be broken in the foreseeable future. > UDP fragmentation also has some downside in lossy radio networks. > > Q: Should there be nested container syntax that is actually self- > describing? (i.e. type flag that indicates container, no body except > sub-TLVs?) > > A: Not for now, but perhaps valid design.. TBD. > > > Q: Why not doing (performance thing X, Y or Z)? > > A: This is designed mostly to be minimal (only timers Trickle ones; > everything triggered by Trickle-driven messages or local state > changes). However, feel free to suggest better (even more minimal) > design which works. The biggest obvious question to me is why is it desirable to negotiate a common Homenet routing protocol on the fly? Upside is that it avoids a heated debate for now. But what else does it deliver? Downside is you are likely going to get huge code bloat. And developers will have to maintain and debug multiple code streams that may be only run infrequently. Not a great combination in devices that traditionally have a poor record of running the latest and greatest code. You may also import massive instability and long convergence times: neighbors that have a determining vote in which routing protocol is chosen may disappear temporarily, meaning that an entirely different routing family is chosen, only for these routers (e.g. tethered mobile) to re-appear a couple of minutes later, meaning the whole process has to be undone. What happens when some neighbors have been updated for HNCP before others that they now need to run OSPF, but the existing protocol was Babel? Does the Homenet have to shut down all forwarding while the trickle updates converge, to avoid potential routing loops? Different routing protocols may well make different forwarding decisions, especially if their potential next-hop neighbor hasn't even started speaking a particular protocol yet. And if you are going to do this, you'd better include subversions, as features are added e.g. OSPFv4 may be preferred over an older alternative routing family whereas OSPFv2 would not. >> http://tools.ietf.org/html/draft-stenberg-homenet-dnssd-hybrid-proxy-zeroconf-00 >> http://tools.ietf.org/html/draft-pfister-homenet-prefix-assignment-00 >> >> Experimental partial implementation: >> https://github.com/sbyx/hnetd/ >> >> Discuss. >> >> Cheers, >> >> -Markus >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet > -- Regards, RayH From nobody Fri Feb 14 10:17:59 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C267F1A02CF; Fri, 14 Feb 2014 10:17:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ww6mQDYxYd3S; Fri, 14 Feb 2014 10:17:57 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 181F61A036E; Fri, 14 Feb 2014 10:17:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214181753.13350.92327.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 10:17:53 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/3L-NDIqOrsN_gzrkB2baO-qxRFU Cc: homenet@ietf.org Subject: [homenet] I-D Action: draft-ietf-homenet-arch-12.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 18:17:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Home Networking Working Group of the IETF. Title : IPv6 Home Networking Architecture Principles Authors : Tim Chown Jari Arkko Anders Brandt Ole Troan Jason Weil Filename : draft-ietf-homenet-arch-12.txt Pages : 52 Date : 2014-02-14 Abstract: This text describes evolving networking technology within residential home networks with increasing numbers of devices and a trend towards increased internal routing. The goal of this document is to define a general architecture for IPv6-based home networking, describing the associated principles, considerations and requirements. The text briefly highlights specific implications of the introduction of IPv6 for home networking, discusses the elements of the architecture, and suggests how standard IPv6 mechanisms and addressing can be employed in home networking. The architecture describes the need for specific protocol extensions for certain additional functionality. It is assumed that the IPv6 home network is not actively managed, and runs as an IPv6-only or dual-stack network. There are no recommendations in this text for the IPv4 part of the network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-homenet-arch/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-homenet-arch-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-arch-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 14 10:21:46 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 522981A03BD for ; Fri, 14 Feb 2014 10:21:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.769 X-Spam-Level: X-Spam-Status: No, score=-1.769 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k80yEwOoRYxM for ; Fri, 14 Feb 2014 10:21:42 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB161A03BB for ; Fri, 14 Feb 2014 10:21:42 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s1EILc6V023338 for ; Fri, 14 Feb 2014 18:21:38 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk s1EILc6V023338 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1392402099; bh=gU97VYWS5GOdWl3tTUznut8OUJw=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=3q/kmvP5P5sLa4W44f81QVGpGmnp+8G6/PuE2jEzDMo8CFYc+1n+blZASDQEK51Hh t7zpDF5qLWnYMoHTG5hK3K93goQDwUTG1mkFL3tl7j8syRX/BbOIywkoyrcxMMbR51 hYUdjYBtGcl47wFWpJBNCo+VErEGnXAcfShPD990= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id q1DILc0959650233DY ret-id none; Fri, 14 Feb 2014 18:21:38 +0000 Received: from tjc-vpn.ecs.soton.ac.uk (tjc-vpn.ecs.soton.ac.uk [152.78.236.241]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s1EILbq7006854 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 14 Feb 2014 18:21:37 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Tim Chown In-Reply-To: <20140214181753.13350.92327.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 18:21:36 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20140214181753.13350.92327.idtracker@ietfa.amsl.com> To: homenet@ietf.org X-Mailer: Apple Mail (2.1827) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=q1DILc095965023300; tid=q1DILc0959650233DY; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: s1EILc6V023338 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/5WSmCpbm4ID_z-cIai6C9FzrbC0 Subject: [homenet] New arch text: draft-ietf-homenet-arch-12.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 18:21:45 -0000 Hi, For info, this draft is intended to address any remaining IESG comments. = Emails have been sent to the ADs in question with the chairs copied. = We hope that any remaining DISCUSSes can be cleared before London. Tim On 14 Feb 2014, at 18:17, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Home Networking Working Group of the = IETF. >=20 > Title : IPv6 Home Networking Architecture Principles > Authors : Tim Chown > Jari Arkko > Anders Brandt > Ole Troan > Jason Weil > Filename : draft-ietf-homenet-arch-12.txt > Pages : 52 > Date : 2014-02-14 >=20 > Abstract: > This text describes evolving networking technology within = residential > home networks with increasing numbers of devices and a trend towards > increased internal routing. The goal of this document is to define = a > general architecture for IPv6-based home networking, describing the > associated principles, considerations and requirements. The text > briefly highlights specific implications of the introduction of IPv6 > for home networking, discusses the elements of the architecture, and > suggests how standard IPv6 mechanisms and addressing can be employed > in home networking. The architecture describes the need for = specific > protocol extensions for certain additional functionality. It is > assumed that the IPv6 home network is not actively managed, and runs > as an IPv6-only or dual-stack network. There are no recommendations > in this text for the IPv4 part of the network. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-homenet-arch/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-homenet-arch-12 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-homenet-arch-12 From nobody Fri Feb 14 11:29:38 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C3321A02AF for ; Fri, 14 Feb 2014 11:29:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.378 X-Spam-Level: X-Spam-Status: No, score=-0.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_64=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id clXxT17hbCjn for ; Fri, 14 Feb 2014 11:29:34 -0800 (PST) Received: from chi.subsignal.org (cxd-2-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:ed::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7CC8F1A0158 for ; Fri, 14 Feb 2014 11:29:34 -0800 (PST) Received: from [192.168.178.24] (unknown [212.255.47.243]) by chi.subsignal.org (Postfix) with ESMTPSA id 67451126183; Fri, 14 Feb 2014 20:30:38 +0100 (CET) Message-ID: <52FE6E9B.3060107@openwrt.org> Date: Fri, 14 Feb 2014 20:29:31 +0100 From: Steven Barth User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10 MIME-Version: 1.0 To: Ray Hunter References: <58809B4D-CCE4-4DAC-9A1A-DD475584E65B@iki.fi> <6BF5B681-446C-4BCA-9B53-A05A9D4A9E38@townsley.net> <52FE480F.3030801@globis.net> In-Reply-To: <52FE480F.3030801@globis.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/NyNisxJI-_IzCdGdsx0mYhiNIKg Cc: "homenet@ietf.org Group" , markus.stenberg@iki.fi, Mark Townsley Subject: Re: [homenet] HNCP X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 19:29:36 -0000 On 14.02.2014 17:45, Ray Hunter wrote: > > The biggest obvious question to me is why is it desirable to negotiate > a common Homenet routing protocol on the fly? > > Upside is that it avoids a heated debate for now. But what else does > it deliver? I think your arguments about the downsides are valid and we have thought about them as well. However the current approach seems to be practical given the current situation that there is no common consensus about an IGP or about there even being an IGP that fits all use cases. Some people even argue that in some or many common cases an IGP might be overkill. On top of that I even think if there would be a consensus in the near future then we still need autoconfiguration and source+dest routing standardized and adopted for that given IGP which will probably take quite some time as well. So yes, there are limitations and hopefully this is not the final stance on this topic and at some point there is some kind of industry-consensus on an IGP. But honestly I don't see this happening any time soon. From nobody Fri Feb 14 15:12:25 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 531B31A0343 for ; Fri, 14 Feb 2014 15:12:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fxnmWb56-0sv for ; Fri, 14 Feb 2014 15:12:20 -0800 (PST) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) by ietfa.amsl.com (Postfix) with ESMTP id 188C61A0414 for ; Fri, 14 Feb 2014 15:12:20 -0800 (PST) Received: by mail-qg0-f51.google.com with SMTP id q108so2324941qgd.10 for ; Fri, 14 Feb 2014 15:12:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=UGPTxPGZUMkLbMvdMUJFfJO9Wleih9BLb6HQU5JpPtM=; b=TXI+4qzonI8809B/aluCYeOE0VJ/8plUIuCJxqh3xXwFkQHaTn4qUjEDbOT1n+cJZ2 rW4U0B+6fHKH1hBqmo41nEHFUyeEGUTOOVW8A82yevfbsWSRi6XSbYEu6K1ioVwEYylD SimD7BGDDIkFTlt9oWl6A8HSJCEQIdftABNRBZMZpyMJPvHnknHestvmppI0uTxveAIm nN3DpDVP309d2e8JMKzTjALSThcXUL+9cAvBAxVkVQAbs2vi/eL6ppSFc3ecEVaAD+HA hIgMW94JZQeZBVj5i+8N7j9rPuh2My/uqEYezvFhqhAHo14spwPOMdehs5MchZIOjna5 5/Cw== MIME-Version: 1.0 X-Received: by 10.224.30.16 with SMTP id s16mr18097759qac.74.1392419538255; Fri, 14 Feb 2014 15:12:18 -0800 (PST) Received: by 10.224.27.133 with HTTP; Fri, 14 Feb 2014 15:12:18 -0800 (PST) Date: Fri, 14 Feb 2014 15:12:18 -0800 Message-ID: From: Dave Taht To: HOMENET , Simon Kelley , Evan Hunt Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/w2Sj3NxzE7GHwJgUUgKyMx90shs Subject: [homenet] RFC: dhcpv4 to slaac DNS naming scheme X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 23:12:22 -0000 I had intended to submit this to the homenet wg, but appear to have goofed in some way in getting it to the right place. presently at: http://datatracker.ietf.org/doc/draft-taht-kelley-hunt-dhcpv4-to-slaac-nami= ng/ Abstract This memo presents a technique for using the hostname acquired from a DHCPv4 client request to publish AAAA records on that domain name for public IPv6 addresses acquired by the same dual-stack host using SLAAC. On dual-stack networks, there is a need to automatically publish entries in the DNS for the public IPv6 addresses of an IPv6 host when it does not use DHCPv6. IPv6 hosts can acquire IPv6 addresses using SLAAC, but there is no mechanism allowing them to register a name in the DNS database other than a DNS update, which would create a very difficult key management problem. By combining the DHCPv4 hostname or client FQDN option with information acquired using ICMPv6, a lightweight DHCPv4 server on a home gateway or SOHO gateway can automatically publish AAAA records for such hosts. --=20 Dave T=E4ht From nobody Fri Feb 14 18:19:24 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28FC61A02E0 for ; Fri, 14 Feb 2014 18:19:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GUMCbv1ygfnu for ; Fri, 14 Feb 2014 18:19:18 -0800 (PST) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id B4FF81A005F for ; Fri, 14 Feb 2014 18:19:18 -0800 (PST) Received: by mail-ob0-f179.google.com with SMTP id wo20so14707472obc.24 for ; Fri, 14 Feb 2014 18:19:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=5FhvoX0s7bu5cgtdjb6YyfcdhjO5ckasIgwP1Nwhq9w=; b=eAAVJWHNT+O0DvbxNFqi9daOD8Lgjc52JbtMN26NtqAn9yOwn19dhi4HQQe6P6ynAK JzGNlCnvQ4vcBdWVTbR5mDdyeQ1X3IDZcb6lpKtOBvN9mRi1z23WVjYxo5PaRBrtijBi p83CstN2za3/nKVFmKCOuHmFbxjyQTdGrCg57selyHUkQd65I2QHcEQwTKrXDZjzjySz re9r7rKGoBya5A4VH+YPDs8Iq1n7ml//Ty91nB1HRA4c0+W0PTNgzX5KWATKLa+kSN2t 0vjg2aj3mlyC60iwKD6dpa70Dp5zsJyJTVub6MgTVxYO5AmTx0+xBbXUKRql2a0b/TXd crXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=5FhvoX0s7bu5cgtdjb6YyfcdhjO5ckasIgwP1Nwhq9w=; b=RWMOXJK1cl1MNLGZcu6WzASVhhmFQkoiXA0oV1QOKCO2FM3evKWVKqRKsnYq+hBUof 88SaoSoGP1wY698cwBIMO/K2veKUibsWGD8Ahh6aVvlCyasD2+WrFKwv0k+ABUd1ZSRh paLIVVLMKOSGwuNN0ImJHj6roDrGSvoL/z/NJsKAU6VuGleLtSsR9iI/OckE076BUCmZ J7ZdxCErzfowAyJdWnRa6vALNQ0CqmUdqsr7+7RqNoCB3bG90IozlbzOIMAZL0iXeRfV tMnriKhHcubE+tFFKHfVEVNhsC1AaTE/Qeet3NnS3x6i0hDFDbKfAhOE56OQldcI1hZa /zuw== X-Gm-Message-State: ALoCoQljLMd6j6DHnRa/Qq/kV/60wElui9Rt3v55j24woW/rL/VNUJju8dwd1qDnkC3d8c+nXiSm5yaEpnbI3izLUqBzymrkgEl77Ch5S1qo8W8mm6yI1cTM1Ko0Tn4RCHT7HHpE1MWDl0kE1FX5OdydgYjjtRoMMeF2guDlUCOKx+jS/QQf50t6pzNQxWBHB6fepR1Iosep X-Received: by 10.182.22.18 with SMTP id z18mr9380076obe.42.1392430756862; Fri, 14 Feb 2014 18:19:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.89.229 with HTTP; Fri, 14 Feb 2014 18:18:55 -0800 (PST) In-Reply-To: References: From: Lorenzo Colitti Date: Sat, 15 Feb 2014 11:18:55 +0900 Message-ID: To: Dave Taht Content-Type: multipart/alternative; boundary=001a11332d16a346b504f2688ccf Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/86TI-Pe0DEBeCBY-AMgqinPfC7Q Cc: Evan Hunt , Simon Kelley , HOMENET Subject: Re: [homenet] RFC: dhcpv4 to slaac DNS naming scheme X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 02:19:22 -0000 --001a11332d16a346b504f2688ccf Content-Type: text/plain; charset=UTF-8 On Sat, Feb 15, 2014 at 8:12 AM, Dave Taht wrote: > This memo presents a technique for using the hostname acquired from a > DHCPv4 client request to publish AAAA records on that domain name for > public IPv6 addresses acquired by the same dual-stack host using > SLAAC. > Dave, Good to see some work being done on this problem. A few comments: 1. Assuming that hosts generate IPv6 interface IDs per RFC 4291 will soon be mostly obsolete. As you point out, Windows already doesn't do it, and I believe Mac OS and iOS have recently stopped doing it too. So that's a large chunk of the client population already. For the rest, see http://tools.ietf.org/html/draft-gont-6man-deprecate-eui64-based-addresses-00, which is likely going to be adopted by 6man. It likely won't deprecate EUI-64-based IPv6 addresses, but it will almost certainly discourage them. As you also point out, the proposed mechanism also doesn't work for privacy addresses, which is what virtually all hosts are going to be using for outgoing connections anyway. So I don't think that the proposed scheme is a solution to the problem. 2. Since you propose getting this information using MAC addresses, you're doing layering violations and protocol violations already. So why not go a step further and look into the neighbour cache? In principle, you could have the reverse DNS lookup cause a lookup into the IPv6 neighbour cache to find the address that you would then look up in the DHCP lease database. That's expensive, but you could cache the result, and you could also snoop DAD probes to populate the cache when hosts join the network. That would work in a lot more cases than the proposed scheme. 3. If we're going to do work on this, it would be useful to have a mechanism that works even without IPv4. The draft says that relying on dynamic DNS updates "creates a very difficult key management problem", but I don't understand that statement. Can we not simply use unauthenticated DNS updates, and agree to accept them only if they come from the local link? After all, in the proposed scheme the DHCPv4 request that provides the hostname is also unauthenticated, but the router is perfectly happy to accept it. What is the additional security difficulty here? Is is something that could be worked out in a different way? Assuming client support, could the hostname be provided by other types of packets such as ICMPv6 node information replies? Regards, Lorenzo --001a11332d16a346b504f2688ccf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= at, Feb 15, 2014 at 8:12 AM, Dave Taht <dave.taht@gmail.com> wrote:
=C2=A0 =C2=A0This memo pr= esents a technique for using the hostname acquired from a
=C2=A0 =C2=A0DHCPv4 client request to publish AAAA records on that domain n= ame for
=C2=A0 =C2=A0public IPv6 addresses acquired by the same dual-stack host usi= ng
=C2=A0 =C2=A0SLAAC.

Dave,
Good to see some work being done on this problem. A few comment= s:

1. Assuming that hosts generate IPv6 interface = IDs per RFC 4291 will soon be mostly obsolete. As you point out, Windows al= ready doesn't do it, and I believe Mac OS and iOS have recently stopped= doing it too. So that's a large chunk of the client population already= . For the rest, see=C2=A0http://tools.ietf.org/html/draft-go= nt-6man-deprecate-eui64-based-addresses-00 , which is likely going to b= e adopted by 6man. It likely won't deprecate EUI-64-based IPv6 addresse= s, but it will almost certainly discourage them. As you also point out, the= proposed mechanism also doesn't work for privacy addresses, which is w= hat virtually all hosts are going to be using for outgoing connections anyw= ay. So I don't think that the proposed scheme is a solution to the prob= lem.

2. Since you propose getting this information using MAC= addresses, you're doing layering violations and protocol violations al= ready. So why not go a step further and look into the neighbour cache? In p= rinciple, you could have the reverse DNS lookup cause a lookup into the IPv= 6 neighbour cache to find the address that you would then look up in the DH= CP lease database. That's expensive, but you could cache the result, an= d you could also snoop DAD probes to populate the cache when hosts join the= network. That would work in a lot more cases than the proposed scheme.

3. If we're going to do work on this, it would be u= seful to have a mechanism that works even without IPv4. The draft says that= relying on dynamic DNS updates "creates a very difficult key manageme= nt problem", but I don't understand that statement. Can we not sim= ply use unauthenticated DNS updates, and agree to accept them only if they = come from the local link? After all, in the proposed scheme the DHCPv4 requ= est that provides the hostname is also unauthenticated, but the router is p= erfectly happy to accept it. What is the additional security difficulty her= e? Is is something that could be worked out in a different way? Assuming cl= ient support, could the hostname be provided by other types of packets such= as ICMPv6 node information replies?

Regards,
Lorenzo
--001a11332d16a346b504f2688ccf-- From nobody Sat Feb 15 01:24:00 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F127D1A013F for ; Sat, 15 Feb 2014 01:23:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_51=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cj83NhHGc-NU for ; Sat, 15 Feb 2014 01:23:57 -0800 (PST) Received: from eyas.biff.org.uk (eyas.biff.org.uk [IPv6:2001:41c8:1:519c::20]) by ietfa.amsl.com (Postfix) with ESMTP id D0DBF1A013C for ; Sat, 15 Feb 2014 01:23:56 -0800 (PST) Received: from cl-1441.lon-02.gb.sixxs.net ([2a01:348:6:5a0::2]:56345 helo=central.thekelleys.org.uk) by eyas.biff.org.uk with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1WEbTS-0000Y4-LJ; Sat, 15 Feb 2014 09:23:50 +0000 Received: from archie.thekelleys.org.uk ([192.168.1.167]) by central.thekelleys.org.uk with esmtpa (Exim 4.72) (envelope-from ) id 1WEbTS-0005wN-1v; Sat, 15 Feb 2014 09:23:50 +0000 Message-ID: <52FF3228.8060108@thekelleys.org.uk> Date: Sat, 15 Feb 2014 09:23:52 +0000 From: Simon Kelley User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Lorenzo Colitti , Dave Taht References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/3VLVTkGrEuPlViRw2qN477Sds8E Cc: Evan Hunt , HOMENET Subject: Re: [homenet] RFC: dhcpv4 to slaac DNS naming scheme X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 09:23:59 -0000 On 15/02/14 02:18, Lorenzo Colitti wrote: > On Sat, Feb 15, 2014 at 8:12 AM, Dave Taht > wrote: > > This memo presents a technique for using the hostname acquired > from a > DHCPv4 client request to publish AAAA records on that domain > name for > public IPv6 addresses acquired by the same dual-stack host using > SLAAC. > > > Dave, > > Good to see some work being done on this problem. A few comments: > > 1. Assuming that hosts generate IPv6 interface IDs per RFC 4291 will > soon be mostly obsolete. As you point out, Windows already doesn't do > it, and I believe Mac OS and iOS have recently stopped doing it too. So > that's a large chunk of the client population already. For the rest, see > http://tools.ietf.org/html/draft-gont-6man-deprecate-eui64-based-addresses-00 > , which is likely going to be adopted by 6man. It likely won't deprecate > EUI-64-based IPv6 addresses, but it will almost certainly discourage > them. As you also point out, the proposed mechanism also doesn't work > for privacy addresses, which is what virtually all hosts are going to be > using for outgoing connections anyway. So I don't think that the > proposed scheme is a solution to the problem. This technique is useful for all the _existing_ systems that only do EUI64 SLAAC, I don't think it's something we should do going forward. It might be worth pointing out that deprecate-eui64-based-addresses goes backwards in this respect, and deprecate-eui64-based-addresses-and use-dhcpv6-instead would be better, or define a hostname option in the Router Solicit packet. > > 2. Since you propose getting this information using MAC addresses, > you're doing layering violations and protocol violations already. So why > not go a step further and look into the neighbour cache? In principle, > you could have the reverse DNS lookup cause a lookup into the IPv6 > neighbour cache to find the address that you would then look up in the > DHCP lease database. That's expensive, but you could cache the result, > and you could also snoop DAD probes to populate the cache when hosts > join the network. That would work in a lot more cases than the proposed > scheme. > Two reasons. 1) Using ICMP6 works even when the client is not a neighbour of the server, ie when it's on a remote network segment and DHCPv4 relay is in use. 2) Implementation. There'a a well defined, stable and universal API to send and recieve ICMP6 packets. The same code runs everywhere. Snooping the ND takes code that's platform specific and rather more complex. Cheers, Simon. From nobody Sat Feb 15 02:36:05 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E3D61A0199 for ; Sat, 15 Feb 2014 02:36:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R4rWt4xFfcah for ; Sat, 15 Feb 2014 02:36:02 -0800 (PST) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id E823F1A0107 for ; Sat, 15 Feb 2014 02:36:01 -0800 (PST) Received: by mail-ig0-f172.google.com with SMTP id k19so2387680igc.5 for ; Sat, 15 Feb 2014 02:35:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=5Nin7pQ+caIWIm2uNCifs1YDNHov/qjbBWsVRjankYg=; b=g2GpKEpKuMDLfuo25am5giDI5NxmJJ+gfpWZqONiTd5wGU1F5oN7KhVQiGb2MF++rD ja9mBcJwZ+UfOp3om3uCvetRuAkCfBgEX7GKnzF4qfKf+UdzQFdvtelBgfAmgojbcnaz JOmo4xF+YyKPrn83PaXwOFUeYdqyPSlEfRzZwZ4DxAEA5WmdVJKIfov/tZ0/BqzRamed OLcd4A20C4CDc422TvGw0tLDbcNRwbO2MdM6GNv1O6RdyZwA4v+Mun4VLgOAzUPVyiZa wNCwFcckTIojVBB2LX1uQ8nvzNzaDdE5NYRjLm7CdFzs0hvDxaArYFskSuwvMsScvja8 /oBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=5Nin7pQ+caIWIm2uNCifs1YDNHov/qjbBWsVRjankYg=; b=FCHzK3ttQvJwr5btrIkPP8dt4UQfD5+hgToyD8FiduLTfV/joq7QDm322+bAuViWD3 2bBX2fTEVva6w4Q2csxTDgQffuU1WyZMJ0tgrSNRsMQwbkb72Muot1ah1RsnPmWY2kXQ +Bfy4NpnLiWkpGF4+svrjMoGxEdSuKkygXuUK4luI1kKsD7LOXyg987kZZhev89A/VYm pGEQDDVVn0SMu16Jb6mffNjIcsHL4GUzCWFG6zzhLEf16KQp2Mx87fh4owf9suac9uLZ KJodjwvlMzitGUJMIsfHKI/JlLr2AX4NaqlOq7ebHtRfs+ONyaY4d6k1k+4c1TX3cO59 A6Rg== X-Gm-Message-State: ALoCoQncAJcA+bJU+58+eE8iqw3mSJHn4CrinBEmvTp3kuEZ0skl333vKyhLxg4JydBek3KiLT4STqvO9SasafVgntwQBWUoiDHQsmDOsGrnu1K0kqSlTD1oxCyJAuDt6dQ759VYiOrCvCqMkp7NDSkzovKy+Hz1PnDa0TIXsLfBEssltitQwgs4FDROFRL4Po3PvhUlMkif X-Received: by 10.50.79.234 with SMTP id m10mr7088158igx.47.1392460559480; Sat, 15 Feb 2014 02:35:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.18.136 with HTTP; Sat, 15 Feb 2014 02:35:39 -0800 (PST) In-Reply-To: <52FF3228.8060108@thekelleys.org.uk> References: <52FF3228.8060108@thekelleys.org.uk> From: Lorenzo Colitti Date: Sat, 15 Feb 2014 19:35:39 +0900 Message-ID: To: Simon Kelley Content-Type: multipart/alternative; boundary=089e0122a59c032cec04f26f7d52 Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/XY2S-yvNLXcsfTer56w1hrxbLBk Cc: Evan Hunt , HOMENET , Dave Taht Subject: Re: [homenet] RFC: dhcpv4 to slaac DNS naming scheme X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 10:36:03 -0000 --089e0122a59c032cec04f26f7d52 Content-Type: text/plain; charset=UTF-8 On Sat, Feb 15, 2014 at 6:23 PM, Simon Kelley wrote: > This technique is useful for all the _existing_ systems that only do EUI64 > SLAAC, I don't think it's something we should do going forward. > Which ones are those, though? I mean - we can certainly write this up as is, but if it doesn't work on Windows, Mac OS, or iOS, then... how much use will it be in the real world? Given that homenet device implementation resources are not unlimited, perhaps we should try to define things that have more impact on devices that people use. --089e0122a59c032cec04f26f7d52 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= at, Feb 15, 2014 at 6:23 PM, Simon Kelley <simon@thekelleys.org.uk> wrote:
This technique is useful for= all the _existing_ systems that only do EUI64 SLAAC, I don't think it&= #39;s something we should do going forward.

Which ones are those, though? I mean - we = can certainly write this up as is, but if it doesn't work on Windows, M= ac OS, or iOS, then... how much use will it be in the real world? Given tha= t homenet device implementation resources are not unlimited, perhaps we sho= uld try to define things that have more impact on devices that people use.<= /div>
--089e0122a59c032cec04f26f7d52-- From nobody Sat Feb 15 02:45:02 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92F5C1A017B for ; Sat, 15 Feb 2014 02:45:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AfX1vcWm2gDw for ; Sat, 15 Feb 2014 02:44:58 -0800 (PST) Received: from eyas.biff.org.uk (eyas.biff.org.uk [IPv6:2001:41c8:1:519c::20]) by ietfa.amsl.com (Postfix) with ESMTP id DC4001A0179 for ; Sat, 15 Feb 2014 02:44:57 -0800 (PST) Received: from cpc11-cmbg17-2-0-cust618.5-4.cable.virginm.net ([86.30.118.107]:41059 helo=central.thekelleys.org.uk) by eyas.biff.org.uk with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1WEcjt-0000xx-TF; Sat, 15 Feb 2014 10:44:54 +0000 Received: from archie.thekelleys.org.uk ([192.168.1.167]) by central.thekelleys.org.uk with esmtpa (Exim 4.72) (envelope-from ) id 1WEcjt-0007xy-AM; Sat, 15 Feb 2014 10:44:53 +0000 Message-ID: <52FF4527.20403@thekelleys.org.uk> Date: Sat, 15 Feb 2014 10:44:55 +0000 From: Simon Kelley User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Lorenzo Colitti References: <52FF3228.8060108@thekelleys.org.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/klHaZh_oyKUryWqttZTmJe4mLG0 Cc: Evan Hunt , HOMENET , Dave Taht Subject: Re: [homenet] RFC: dhcpv4 to slaac DNS naming scheme X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 10:45:00 -0000 On 15/02/14 10:35, Lorenzo Colitti wrote: > On Sat, Feb 15, 2014 at 6:23 PM, Simon Kelley > wrote: > > This technique is useful for all the _existing_ systems that only do > EUI64 SLAAC, I don't think it's something we should do going forward. > > > Which ones are those, though? I mean - we can certainly write this up as > is, but if it doesn't work on Windows, Mac OS, or iOS, then... how much > use will it be in the real world? The obvious answer is Android, which is what it was originally implemented for. I think the three platforms you mention have have DHCPv6 support, Android doesn't, or at least didn't: I'm not sure about the latest releases. From nobody Sat Feb 15 03:19:39 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79C381A01A8 for ; Sat, 15 Feb 2014 03:19:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.194 X-Spam-Level: X-Spam-Status: No, score=0.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nPFCEhjCVZT9 for ; Sat, 15 Feb 2014 03:19:36 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5181D1A0117 for ; Sat, 15 Feb 2014 03:19:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 3F5C137; Sat, 15 Feb 2014 12:19:34 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tougVXbDNNci; Sat, 15 Feb 2014 12:19:32 +0100 (CET) Received: from [IPv6:2a00:8640:1::c9aa:fdd:8b14:c42a] (unknown [IPv6:2a00:8640:1:0:c9aa:fdd:8b14:c42a]) by mail.sintact.nl (Postfix) with ESMTPSA id DCFCC34; Sat, 15 Feb 2014 12:19:31 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Sander Steffann In-Reply-To: Date: Sat, 15 Feb 2014 12:19:31 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <40475695-8913-4763-8861-1FE3F2BA944D@steffann.nl> References: <52FF3228.8060108@thekelleys.org.uk> To: Lorenzo Colittf X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/60F-D5y3igYirn5CUHZQXS_Xglg Cc: Evan Hunt , Simon Kelley , HOMENET , Dave Taht Subject: Re: [homenet] RFC: dhcpv4 to slaac DNS naming scheme X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 11:19:37 -0000 Op 15 feb. 2014, om 11:35 heeft Lorenzo Colitti het = volgende geschreven: > Which ones are those, though? I mean - we can certainly write this up = as is, but if it doesn't work on Windows, Mac OS, or iOS, then... how = much use will it be in the real world? Given that homenet device = implementation resources are not unlimited, perhaps we should try to = define things that have more impact on devices that people use. +1 Sander From nobody Sat Feb 15 03:44:59 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3DC21A00D5 for ; Sat, 15 Feb 2014 03:44:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.194 X-Spam-Level: X-Spam-Status: No, score=0.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dkreKHwLaxpQ for ; Sat, 15 Feb 2014 03:44:55 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.6]) by ietfa.amsl.com (Postfix) with ESMTP id BF0D21A01BE for ; Sat, 15 Feb 2014 03:44:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 98DD637; Sat, 15 Feb 2014 12:44:53 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bvfUsyqt1mo1; Sat, 15 Feb 2014 12:44:51 +0100 (CET) Received: from macpro.10ww.steffann.nl (macpro.10ww.steffann.nl [37.77.56.75]) by mail.sintact.nl (Postfix) with ESMTPSA id 1BE1D34; Sat, 15 Feb 2014 12:44:51 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Sander Steffann In-Reply-To: <52FF4527.20403@thekelleys.org.uk> Date: Sat, 15 Feb 2014 12:44:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <683B985C-4B46-4656-B347-A68CBAF31A30@steffann.nl> References: <52FF3228.8060108@thekelleys.org.uk> <52FF4527.20403@thekelleys.org.uk> To: Simon Kelley X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/hEkEvT6hdNtZ6eEWdLsxUnya5lU Cc: Evan Hunt , HOMENET , Dave Taht , Lorenzo Colittf Subject: Re: [homenet] RFC: dhcpv4 to slaac DNS naming scheme X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 11:44:57 -0000 Hi, Op 15 feb. 2014, om 11:44 heeft Simon Kelley = het volgende geschreven: > On 15/02/14 10:35, Lorenzo Colitti wrote: >> On Sat, Feb 15, 2014 at 6:23 PM, Simon Kelley = > > wrote: >>=20 >> This technique is useful for all the _existing_ systems that only = do >> EUI64 SLAAC, I don't think it's something we should do going = forward. >>=20 >>=20 >> Which ones are those, though? I mean - we can certainly write this up = as >> is, but if it doesn't work on Windows, Mac OS, or iOS, then... how = much >> use will it be in the real world? >=20 > The obvious answer is Android, which is what it was originally = implemented for. I think the three platforms you mention have have = DHCPv6 support, Android doesn't, or at least didn't: I'm not sure about = the latest releases. If Android is the only OS that benefits from this mechanism then I don't = think this belongs in Homenet... Or in the IETF. We should develop = interoperable solutions here. Sorry if I sound a bit harsh. This might = have been an interesting solution many years ago, but not today. I think = today this needs to be further integrated with maybe ND / DAD monitoring = to make it work with non-EUI64 addresses. Cheers, Sander From nobody Sat Feb 15 08:44:54 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD3F1A0185 for ; Sat, 15 Feb 2014 08:44:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0RQdRioR_Uhx for ; Sat, 15 Feb 2014 08:44:50 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id E92B51A017C for ; Sat, 15 Feb 2014 08:44:50 -0800 (PST) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 20D9CC9428; Sat, 15 Feb 2014 16:44:38 +0000 (UTC) (envelope-from each@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1392482688; bh=T+5O/W1WkxJcLl2Ys+EuPGbL4GY3X2YpUy5uFXCgHPI=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=TisESfRng+EvmbW2vaNeMvyYwzSTNmdbfoSRLmCbUOXgp4G3HL1E666zsZd12JGh1 Lv5pHwm16ZHKuuzQvmXx7fLzUmovMB9r162JaRGbCf3oyV6QJTECTIuDomLzpUTnhm upj2ceiRnPj6qZp/9aORLzDN/Tr34lNd54XDXjYQ= 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; Sat, 15 Feb 2014 16:44:38 +0000 (UTC) (envelope-from each@isc.org) Received: by bikeshed.isc.org (Postfix, from userid 10292) id 0F267216C31; Sat, 15 Feb 2014 16:44:38 +0000 (UTC) Date: Sat, 15 Feb 2014 16:44:38 +0000 From: Evan Hunt To: Lorenzo Colitti Message-ID: <20140215164438.GC84363@isc.org> References: <52FF3228.8060108@thekelleys.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-DCC--Metrics: post.isc.org; whitelist Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/LfeV_ArTqn8yBO9gbgXS1S4Mr-Q Cc: Simon Kelley , HOMENET , Dave Taht Subject: Re: [homenet] RFC: dhcpv4 to slaac DNS naming scheme X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 16:44:52 -0000 On Sat, Feb 15, 2014 at 07:35:39PM +0900, Lorenzo Colitti wrote: > Which ones are those, though? I mean - we can certainly write this up as > is, but if it doesn't work on Windows, Mac OS, or iOS, then... To be completely honest, this mechanism was invented as a hack to work around the idiosyncrasies of my personal home network. It was Dave who recognized its potential applicability in other environments and documented it (kindly giving me coauthorship credit that I'm not sure I deserve). *I* thought we were just duct-taping together a one-off solution to the sort of problem only IETF people would ever have. That said, I do have three years of real-world operational experience with it, and I observe that it *is* working with all current versions of macos, iOS, android and linux. -- Evan Hunt -- each@isc.org Internet Systems Consortium, Inc. From nobody Sat Feb 15 12:12:08 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E3E11A0283 for ; Sat, 15 Feb 2014 12:12:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s8CAGDUET_CT for ; Sat, 15 Feb 2014 12:12:04 -0800 (PST) Received: from mail-pb0-x236.google.com (mail-pb0-x236.google.com [IPv6:2607:f8b0:400e:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id AA1E71A0289 for ; Sat, 15 Feb 2014 12:12:04 -0800 (PST) Received: by mail-pb0-f54.google.com with SMTP id uo5so13852879pbc.27 for ; Sat, 15 Feb 2014 12:12:02 -0800 (PST) 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=jUv/Ii6Tv+aj9UUczZEiVQ3vTVD9Aix2g5LHZfB5N3M=; b=iV7tVO1C2MQnV+Ihpb6awen2+BifxzZ8UKfvMcssOqfXqX/ZLTj1up3+KE8x3vN6+5 C8qzRazOOCsiWmHRRTvThYkAzF4Mk7hcLtfMagXCzn3vVsQpsiNZae28nl0V06C0Dop8 PNZlweAXFRoQJt6pbyIyunNrGfZrGJ/6jon8kvWU0pQGEvGFS3WaOBvUVrxhSiZRxy+7 7/aLas2Itg7toWSRB0m2y00FjCw3QltPD7VzCTwECccXHyIL6Gtx+pkrDxj1yrxOj8gc S75veHxJoOa5PVGpmVOjvwJmgzfY8Efvp0tdAarmsIIhbERRfbV2TIqjIxeSYg64J1gv CP4w== X-Received: by 10.66.228.37 with SMTP id sf5mr16932850pac.19.1392495122791; Sat, 15 Feb 2014 12:12:02 -0800 (PST) Received: from [192.168.178.23] (153.200.69.111.dynamic.snap.net.nz. [111.69.200.153]) by mx.google.com with ESMTPSA id fk4sm74268014pab.23.2014.02.15.12.12.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 15 Feb 2014 12:12:02 -0800 (PST) Message-ID: <52FFCA08.9090107@gmail.com> Date: Sun, 16 Feb 2014 09:11:52 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Simon Kelley References: <52FF3228.8060108@thekelleys.org.uk> In-Reply-To: <52FF3228.8060108@thekelleys.org.uk> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/l2rsp5lqfp3uGentckEQNJxZ5DE Cc: Evan Hunt , HOMENET , Dave Taht , Lorenzo Colitti Subject: Re: [homenet] RFC: dhcpv4 to slaac DNS naming scheme X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 20:12:06 -0000 Hi, draft-taht-kelley-hunt-dhcpv4-to-slaac-naming-00 says: > IPv6 hosts can acquire IPv6 addresses using > SLAAC, but there is no mechanism allowing them to register a name in > the DNS database other than a DNS update, which creates a very > difficult key management problem. Can you explain that? I understood that Secure Dynamic DNS Update was quite widely deployed. If it can't be readily deployed in homenets, somebody needs to fix that. > The server MUST discard any IPv6 prefixes whose length is not 64, > since hosts cannot assign addresses in these prefixes using SLAAC. SLAAC itself is carefully not limited to /64. IIDs are limited to /64 by RFC 4291 as updated by RFC 7136. See draft-carpenter-6man-why64 for more discussion of this subtlety. I hope we'll be discussing this in 6man in London. > The server MUST discard link-local prefixes. It MAY be configured to > discard site-local prefixes. This would be appropriate of the host > records were being inserted into the global DNS, but not if they were > being inserted into a local DNS view only available within the site. > > Having determined the set of possible IPv6 prefixes (as above) the > implementation then determines a possible interface identifier. It > uses the client's link-layer address contained in the CHADDR field of > the DHCPv4 [RFC2131] packet, or encoded in the client-id as in > FIREWIRE [RFC3146] and applies the procedure given in [RFC4291] para > 2.5.1 to calculate the SLAAC interface identifier. RFC 7136 makes it clear that this is not a reversible transformation (unless you know with absolute certainty that RFC 4291 Appendix A has been applied, which is increasingly rare and likely to be deprecated). So I really don't see how this draft could be standardised; I could see it being published as Informational ("here's something that works in special circumstances"). Brian From nobody Sat Feb 15 12:57:34 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C210B1A02E8 for ; Sat, 15 Feb 2014 12:57:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 86LcG_dzWLMG for ; Sat, 15 Feb 2014 12:57:31 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 60A581A0112 for ; Sat, 15 Feb 2014 12:57:31 -0800 (PST) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id DB705C9496; Sat, 15 Feb 2014 20:57:18 +0000 (UTC) (envelope-from each@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1392497849; bh=Il+E4ISSFZrEelJVifPlL7a+BfYg5qV+Se5El6yW+mU=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=Kjs9ykvg34r7arVq4vZKZdCde2QuM0u/5zpZ686KBds/rFNVmJlzlQfond7TGAojw y3kBvfAhqOvTFP7KVfgbb81q565PrjSD+lW+2Gext28gl8GtckJpeb2clUq76+Sads N9f6Nd+YVW9ua17DLo0Hz8sPZC/G05FUUi9r8Ciw= 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; Sat, 15 Feb 2014 20:57:18 +0000 (UTC) (envelope-from each@isc.org) Received: by bikeshed.isc.org (Postfix, from userid 10292) id CA80B216C31; Sat, 15 Feb 2014 20:57:18 +0000 (UTC) Date: Sat, 15 Feb 2014 20:57:18 +0000 From: Evan Hunt To: Brian E Carpenter Message-ID: <20140215205718.GA89384@isc.org> References: <52FF3228.8060108@thekelleys.org.uk> <52FFCA08.9090107@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52FFCA08.9090107@gmail.com> User-Agent: Mutt/1.4.2.3i X-DCC--Metrics: post.isc.org; whitelist Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/Ifrk-r1xnXB0bp9LXsYF0ye_22I Cc: Simon Kelley , HOMENET , Dave Taht , Lorenzo Colitti Subject: Re: [homenet] RFC: dhcpv4 to slaac DNS naming scheme X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 20:57:33 -0000 > > IPv6 hosts can acquire IPv6 addresses using > > SLAAC, but there is no mechanism allowing them to register a name in > > the DNS database other than a DNS update, which creates a very > > difficult key management problem. > > Can you explain that? I understood that Secure Dynamic DNS Update > was quite widely deployed. If it can't be readily deployed in homenets, > somebody needs to fix that. It can be, and is. However, if the *host* is registering a name in the DNS, then it must be configured in advance with a suitable key. If the *router* manages everything, then it needs to know all the pieces of the puzzle -- hostname, v4 address(es), v6 address(es) -- and that's not always straightforward with architectures in which the v4 and v6 address spaces are managed by different software, possibly running on different servers. The slaac mechanism allows a dhcpv4 daemon to make an educated guess at a usable v6 address for a host, confirm it, and act on it, either by sending a suitable DNS update or (for something like dnsmasq, which acts as both DHCP and DNS server) updating its own internal state. -- Evan Hunt -- each@isc.org Internet Systems Consortium, Inc. From nobody Sat Feb 15 14:23:43 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFDB61A02D8 for ; Sat, 15 Feb 2014 14:23:40 -0800 (PST) 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=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQZ3tF4gBihS for ; Sat, 15 Feb 2014 14:23:38 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 463221A02E1 for ; Sat, 15 Feb 2014 14:23:38 -0800 (PST) Received: from [IPv6:2001:470:88a3::495d:6224:9fbc:ce18] (unknown [IPv6:2001:470:88a3:0:495d:6224:9fbc:ce18]) by toccata.fugue.com (Postfix) with ESMTPSA id 55E702380477; Sat, 15 Feb 2014 17:23:34 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ted Lemon In-Reply-To: <20140215205718.GA89384@isc.org> Date: Sat, 15 Feb 2014 17:23:32 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <3347CA47-EA07-4B10-AB0C-FA53EAE85BE4@fugue.com> References: <52FF3228.8060108@thekelleys.org.uk> <52FFCA08.9090107@gmail.com> <20140215205718.GA89384@isc.org> To: Evan Hunt X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/lfxNFAXm3Keev3wqjfE-h1Dnb6Y Cc: Simon Kelley , HOMENET , Lorenzo Colitti , Dave Taht Subject: Re: [homenet] RFC: dhcpv4 to slaac DNS naming scheme X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 22:23:41 -0000 It's probably worth pointing out that this is essentially an ops = document, not a protocol spec. =46rom an ops perspective, it's = perfectly reasonable. I offered Dave the same criticism about ND that = Lorenzo did when he asked me to look at it, and I still think looking in = the neighbor table makes more sense than sending ICMP messages. But = fundamentally I think this is a useful hack, and worth writing an ops = document about. I don't know that homenet needs to be where the doc is = published, but that's a separate issue. From nobody Sat Feb 15 14:32:00 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59AA01A00AA for ; Sat, 15 Feb 2014 14:31:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MTJwMRt5ENkt for ; Sat, 15 Feb 2014 14:31:57 -0800 (PST) Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) by ietfa.amsl.com (Postfix) with ESMTP id CEBF21A0049 for ; Sat, 15 Feb 2014 14:31:56 -0800 (PST) Received: by mail-wg0-f54.google.com with SMTP id l18so1325426wgh.9 for ; Sat, 15 Feb 2014 14:31:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=zrB6UFsL7t60gyWEUwbSvSSEm/n8w8Kp9RZiq7nvpDY=; b=A3K2EnDFQvcSllrZkSTQbl9Uu+j+S71lMLlIt5FR0s/xgcCVveoYAgwtlyr3W5L0Ty TyuK1fTVBfWUMWUW3/g30JlrVrwg2VdsTqLZo3QUxnlj9GYpKFVJuP2knXsHcTwxH73u 9MDznd3ovG28wV27mkg/uFJd4uCbPiKfCKgdOJXRKAMmlBTjYjtaXQ9e4fgHGvxL0ZE2 X5O+6qAIcZvKsN1p4B5Rxs+uURqFCHj/yb2eBjCE/u/j7PNE9pAW5o4jbu2pHeozS7KX ZRkKk8Cj/nXmryF6S/LhcVhXP3RobMYwT+rxhJQHhcaD4FEM5eD/Yfd7F1aM5oNDn+S0 R/6g== X-Gm-Message-State: ALoCoQk50IEdwiAOI9xLlv3VxOckesPbKi1mmoR6WM+3m5t07YQ33kIWF+mv9VC8S96TTmeNbfAZ X-Received: by 10.180.13.197 with SMTP id j5mr7456284wic.14.1392503514367; Sat, 15 Feb 2014 14:31:54 -0800 (PST) Received: from [100.100.244.247] (135.16.90.92.rev.sfr.net. [92.90.16.135]) by mx.google.com with ESMTPSA id f7sm23647524wjb.7.2014.02.15.14.31.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 15 Feb 2014 14:31:53 -0800 (PST) References: <52FF3228.8060108@thekelleys.org.uk> <52FFCA08.9090107@gmail.com> <20140215205718.GA89384@isc.org> <3347CA47-EA07-4B10-AB0C-FA53EAE85BE4@fugue.com> Mime-Version: 1.0 (1.0) In-Reply-To: <3347CA47-EA07-4B10-AB0C-FA53EAE85BE4@fugue.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10B350) From: "Townsley.net" Date: Sat, 15 Feb 2014 23:31:51 +0100 To: Ted Lemon Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/QPzA2KGvfEpkWd_6gyhxYsoXGsA Cc: Evan Hunt , Simon Kelley , HOMENET , Dave Taht , Lorenzo Colitti Subject: Re: [homenet] RFC: dhcpv4 to slaac DNS naming scheme X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 22:31:59 -0000 I think the subtlety here is whether or not homenet recommends doing this by= default in one form or another - as Homenets really don't have the luxury o= f users deciding to do these types of things or not. In that sense, what may= look "operational" in a traditional network with traditional operators, bec= omes part and parcel of what a "Homenet" is or is not.=20 - Mark (Thumbtyped) On Feb 15, 2014, at 11:23 PM, Ted Lemon wrote: > It's probably worth pointing out that this is essentially an ops document,= not a protocol spec. =46rom an ops perspective, it's perfectly reasonable= . I offered Dave the same criticism about ND that Lorenzo did when he aske= d me to look at it, and I still think looking in the neighbor table makes mo= re sense than sending ICMP messages. But fundamentally I think this is a u= seful hack, and worth writing an ops document about. I don't know that hom= enet needs to be where the doc is published, but that's a separate issue. >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From nobody Sat Feb 15 14:47:05 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C5B71A0166 for ; Sat, 15 Feb 2014 14:47:04 -0800 (PST) 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=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZ9bYquqgv4T for ; Sat, 15 Feb 2014 14:47:02 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id D0B501A0133 for ; Sat, 15 Feb 2014 14:47:02 -0800 (PST) Received: from [IPv6:2001:470:88a3::495d:6224:9fbc:ce18] (unknown [IPv6:2001:470:88a3:0:495d:6224:9fbc:ce18]) by toccata.fugue.com (Postfix) with ESMTPSA id 8E3F02380477; Sat, 15 Feb 2014 17:46:59 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ted Lemon In-Reply-To: Date: Sat, 15 Feb 2014 17:46:58 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <0F1B7FD9-287F-4A9C-BEA4-A46A06036F80@fugue.com> References: <52FF3228.8060108@thekelleys.org.uk> <52FFCA08.9090107@gmail.com> <20140215205718.GA89384@isc.org> <3347CA47-EA07-4B10-AB0C-FA53EAE85BE4@fugue.com> To: "Townsley.net" X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/yzz4y3o266O9SEH857_H6i5077I Cc: Evan Hunt , Simon Kelley , HOMENET , Dave Taht , Lorenzo Colitti Subject: Re: [homenet] RFC: dhcpv4 to slaac DNS naming scheme X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 22:47:04 -0000 On Feb 15, 2014, at 5:31 PM, Townsley.net wrote: > I think the subtlety here is whether or not homenet recommends doing = this by default in one form or another - as Homenets really don't have = the luxury of users deciding to do these types of things or not. In that = sense, what may look "operational" in a traditional network with = traditional operators, becomes part and parcel of what a "Homenet" is or = is not.=20 I think what you're talking about is still an ops doc=97it's just a = document that describes how operations are done automatically. Because = I really don't think it's a protocol spec, but I agree with you that it = still needs to be written and makes sense as output of homenet. From nobody Sat Feb 15 23:34:39 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 534DA1A038B for ; Sat, 15 Feb 2014 23:34:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id surRUrvBDpmm for ; Sat, 15 Feb 2014 23:34:36 -0800 (PST) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) by ietfa.amsl.com (Postfix) with ESMTP id 47AFD1A038C for ; Sat, 15 Feb 2014 23:34:36 -0800 (PST) Received: by mail-wi0-f173.google.com with SMTP id hn9so1524522wib.12 for ; Sat, 15 Feb 2014 23:34:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=96Ese9FH2K5ecwGcXdmRNW2n1CoIItUwhF6//44BwY0=; b=egKvNeH2TMyp4v/Queo53ulA6k1S6wEWgOKU19JVSaP7zG12KVbRJdu5jJWyaiHKqu KRTVQXVUAmts1701HHK4pivYNZTsX+G4dUCVfhCWztoIi5SKtCqTwClO6cCVY14oI4bJ rc7R3jf8QzZVewE3DFba/plCS1668E5m0M00yeYafmoawBAyPY96nEEJsc4113PPWQ0s CXuEOJdQYoQKsSRF87n4ZfHu25OsjXcNkyjr8FFiFtrhMuEe0WcW6SmMZJ8rU1Ph+EME CqJOO69WE9G/ziRMhISSAmRyy4PGybFlKkbuIXpm8Mo9keODdLIdTnZkFm2xTkL6JQkf fFjQ== X-Gm-Message-State: ALoCoQm7bqoBq2u0KgMvb72tLVQDGBnVhQbrc0LBGq6UmYoaeCuhbkfmgfBO2YATIpGI0CYZAF// X-Received: by 10.194.119.168 with SMTP id kv8mr8333695wjb.41.1392536073740; Sat, 15 Feb 2014 23:34:33 -0800 (PST) Received: from [100.102.252.200] (190.20.90.92.rev.sfr.net. [92.90.20.190]) by mx.google.com with ESMTPSA id dd3sm26420582wjb.9.2014.02.15.23.34.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 15 Feb 2014 23:34:33 -0800 (PST) References: <52FF3228.8060108@thekelleys.org.uk> <52FFCA08.9090107@gmail.com> <20140215205718.GA89384@isc.org> <3347CA47-EA07-4B10-AB0C-FA53EAE85BE4@fugue.com> <0F1B7FD9-287F-4A9C-BEA4-A46A06036F80@fugue.com> Mime-Version: 1.0 (1.0) In-Reply-To: <0F1B7FD9-287F-4A9C-BEA4-A46A06036F80@fugue.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <4B8EACF6-419E-41C3-873C-2BD0A9555E4C@townsley.net> X-Mailer: iPhone Mail (10B350) From: "Townsley.net" Date: Sun, 16 Feb 2014 08:34:30 +0100 To: Ted Lemon Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/P09OTFEDitXcm_h8Cy-hr-5RNUY Cc: Evan Hunt , Simon Kelley , HOMENET , Dave Taht , Lorenzo Colitti Subject: Re: [homenet] RFC: dhcpv4 to slaac DNS naming scheme X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 07:34:38 -0000 Good we agree on the substance, if not the semantics. On the semantics, I co= uld probably be swayed over a longer conversation.... with beer.=20 - Mark (Thumbtyped) On Feb 15, 2014, at 11:46 PM, Ted Lemon wrote: > On Feb 15, 2014, at 5:31 PM, Townsley.net wrote: >> I think the subtlety here is whether or not homenet recommends doing this= by default in one form or another - as Homenets really don't have the luxur= y of users deciding to do these types of things or not. In that sense, what m= ay look "operational" in a traditional network with traditional operators, b= ecomes part and parcel of what a "Homenet" is or is not. >=20 > I think what you're talking about is still an ops doc=E2=80=94it's just a d= ocument that describes how operations are done automatically. Because I re= ally don't think it's a protocol spec, but I agree with you that it still ne= eds to be written and makes sense as output of homenet. >=20 From nobody Mon Feb 17 02:46:28 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AD851A01CA for ; Mon, 17 Feb 2014 02:46:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gOnSq5Gs0ZHJ for ; Mon, 17 Feb 2014 02:46:24 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id DE71D1A038D for ; Mon, 17 Feb 2014 02:46:23 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id E85779C; Mon, 17 Feb 2014 11:46:20 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id E03329A; Mon, 17 Feb 2014 11:46:20 +0100 (CET) Date: Mon, 17 Feb 2014 11:46:20 +0100 (CET) From: Mikael Abrahamsson To: Mark Townsley In-Reply-To: <6BF5B681-446C-4BCA-9B53-A05A9D4A9E38@townsley.net> Message-ID: References: <58809B4D-CCE4-4DAC-9A1A-DD475584E65B@iki.fi> <6BF5B681-446C-4BCA-9B53-A05A9D4A9E38@townsley.net> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/id_aUg5B3SMV_Am-DldwZIdgsQw Cc: "homenet@ietf.org Group" Subject: Re: [homenet] HNCP X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 10:46:26 -0000 On Thu, 13 Feb 2014, Mark Townsley wrote: >> Drafts: >> http://tools.ietf.org/html/draft-stenberg-homenet-hncp-00 >> http://tools.ietf.org/html/draft-stenberg-homenet-dnssd-hybrid-proxy-zeroconf-00 >> http://tools.ietf.org/html/draft-pfister-homenet-prefix-assignment-00 I have read all of the drafts. I still need to wrap my head around all the details, but I think this is excellent work. It solves most if not all the areas of concern within the home when it comes to service discovery, prefix assignment etc. I am a bit confused about the disposition of the drafts, but I guess it can be carved a lot of different ways, so I don't see this as a problem really. The choice to invent a new transport protocol is a concern, however as things should be fairly modular, let's focus on the mechanisms and architecture, and as far as I can tell, this looks fine. If I understood correctly, there is running code for most of this so it has actually been tested? I think this is extremely good if it has, because getting all of these mechanisms right is the important thing, then we can discuss transport as a separate issue. As I am a router guy, redistribution between protocols is done all the time. It's hairy when you do redistribution between OSPF->BGP->OSPF and BGP->OSPF->BGP etc. There you have some identifier that helps you to stop redistribution loops. Do we need something like this here? If we decide that HNCP is not what we want long term and we want to migrate to something else, there might be the need for redistribution between old and now. How can we prepare for something like this so it's as least distruptive as possible? I was thinking of failover. What happens with a LAN with 1 DR and 3 other routers, and I turn off the DR? There is a prefix, there might be some IA_NA handed out by the DR, and there is a lifetime of the prefixes etc. I can't find the relevant section in the prefix assignment draft that handles this (or it's implicit somewhere and I just missed it). Anyhow, I would like to see a whole new section on this topic that describes what happens in different scenarios with pointers to desired behavior, as described in other sections of the text. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue Feb 18 13:42:20 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E38E1A053D for ; Tue, 18 Feb 2014 13:42:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.229 X-Spam-Level: X-Spam-Status: No, score=-0.229 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_IMAGE_ONLY_12=2.059, HTML_IMAGE_RATIO_06=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_REMOTE_IMAGE=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nHhvLH4BQSLf for ; Tue, 18 Feb 2014 13:42:15 -0800 (PST) Received: from mail-ee0-f45.google.com (mail-ee0-f45.google.com [74.125.83.45]) by ietfa.amsl.com (Postfix) with ESMTP id 622731A0544 for ; Tue, 18 Feb 2014 13:42:15 -0800 (PST) Received: by mail-ee0-f45.google.com with SMTP id b15so8058082eek.4 for ; Tue, 18 Feb 2014 13:42:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:subject:date:message-id:cc:to :mime-version; bh=TCG2ZToAgYw9ZgGN6xNftq1BwodOeDBmcW9ObjhRHAo=; b=CLmHwUS4aRB/ECPplhLSPdR7HPr0onOlynzZ6V9vdGHzDfwem4I0nLod19ECr4o4Wh JvJzrlBBP7SOFwTfyhMLV1UDSD97ZvXFoML7BHF2MmP3iysFAVQvNdxGOWtCme5YuCjj 88Y3Jm2+EmK5dcXBDA9Ae8N+uKkfxnY1ZPsix5nNs0/ff6qZ9fwrsdaj1hcV6d2RTeWe 598lXLozf8RgCMsXR4rQKUNLlmU7VTnOUV3mgDBJPQylX/bu7aYp/RopPi6z6mzk30N/ e+Nb/jRfk4DFBNhQEPJWnu2eEkzHX/VnTl1GB349QRVvO4E4B1g5mL8URVcxG84tKxf+ SgOA== X-Gm-Message-State: ALoCoQmbbHNsSP22qlEnDau3XFwqjIIkIEDWVInNpVmJeWo0KXIE3WJxBzA2CBM3872zUWMPzFSB X-Received: by 10.14.88.131 with SMTP id a3mr11170534eef.64.1392759731913; Tue, 18 Feb 2014 13:42:11 -0800 (PST) Received: from dhcp-10-61-103-62.cisco.com (173-38-208-169.cisco.com. [173.38.208.169]) by mx.google.com with ESMTPSA id u6sm74981310eep.11.2014.02.18.13.42.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 18 Feb 2014 13:42:10 -0800 (PST) From: Mark Townsley Content-Type: multipart/alternative; boundary="Apple-Mail=_77A84F75-7448-4EDF-BC8E-421C482B1194" Date: Tue, 18 Feb 2014 22:42:06 +0100 Message-Id: To: "homenet@ietf.org Group" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/Xbfm3LgMkuz7LZhjxl4SmzTajKk Cc: Ray Bellis , Brian Haberman , Ted Lemon Subject: [homenet] =?windows-1252?q?IETF_89_Agenda=85=2E_delayed=2C_Ray_an?= =?windows-1252?q?d_Mark_on_Vacation_at_the_same_time?= X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 21:42:17 -0000 --Apple-Mail=_77A84F75-7448-4EDF-BC8E-421C482B1194 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Ray is searching for Northern Lights, and I am busy tossing myself down = snowy mountains this week. Thus, neither of us were available to get the = agenda in on time. Apologies to all. Please get in your requests for presentations in this week, Ray and I = will be on top of the agenda creation first thing next week after we = return from our respective respites.=20 - Mark k= --Apple-Mail=_77A84F75-7448-4EDF-BC8E-421C482B1194 Content-Type: multipart/related; type="text/html"; boundary="Apple-Mail=_E6339B48-7203-4EEF-A932-BD01CBE4C199" --Apple-Mail=_E6339B48-7203-4EEF-A932-BD01CBE4C199 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

Ray is searching for Northern Lights, and I am busy tossing myself down snowy mountains this week. Thus, neither of us were available to get the agenda in on time. Apologies to all.

Please get in your requests for presentations in this week, Ray and I will be on top of the agenda creation first thing next week after we return from our respective respites. 

- Mark

k
--Apple-Mail=_E6339B48-7203-4EEF-A932-BD01CBE4C199 Content-Transfer-Encoding: base64 Content-Disposition: inline; filename*0=stock-photo-illustration-of-a-male-and-female-pointing-towards-o; filename*1=ne-another-48892513.jpg Content-Type: image/jpg; x-unix-mode=0600; name="stock-photo-illustration-of-a-male-and-female-pointing-towards-one-another-48892513.jpg" Content-Id: /9j/4AAQSkZJRgABAQEBLAEsAAD/2wBDAAICAgICAQICAgIDAgIDAwYEAwMDAwcFBQQGCAcJCAgH CAgJCg0LCQoMCggICw8LDA0ODg8OCQsQERAOEQ0ODg7/2wBDAQIDAwMDAwcEBAcOCQgJDg4ODg4O Dg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg7/wgARCADhASwDAREA AhEBAxEB/8QAHQABAAICAwEBAAAAAAAAAAAAAAEJAggFBgcEA//EABQBAQAAAAAAAAAAAAAAAAAA AAD/2gAMAwEAAhADEAAAAd/gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQCQACASAAAAAAAAAA AAAQCQAAAYkkgAAAAAAAAAAAAgEgAAGB52auHPG1h2AAAAAAAAAAAAggAkkAA8FKhD5jI7+W4npg AAAAAAAAABia8Ghx1I5I2VN7jkgAVuGkgALFzeYkAAAAAAAAgAgpHPOwAbeFoBkAaGleYALOjcME gAAAAAAEEEknxlMR5UAD7C9w5YA0TK7QAWcG4xBBJIAAAABAIJJBquVVEAA5MvQObB8ZVMazAHZi 7E7OCCCSQAAAAYkkgA1+KgyAAWWG6J0c1KNODzYGRsebmm0AABidZOXORAABBiZEgAHWCtI1WIBt gWkH7FIp52ADYstxMgADo5XKehm/5yAAABBIAABiVSGrwOTLYzYYoDAABvSWKEgg62VGHjJbMbLg kAg4I6wcydqJIJAB46UyAA5EtrKgwAAfqXHntIODKjTxI92LcTlASQCTyU0SNTTaQspO1gEHTypY 8cAAJIAAAO3FzxyZVsa0n7Ft5sQCQAQDoZTsdIPci3s+8EFWBqkAAAAAAAcwd8PKwb8FgpJAAJII B5oU0nCmxxa4ciaOFc5AAAAAAAABJuwWRGYIJAAAINPCsYg9fNhTR4wAAAAAAAOUPhOTLGjckyBB IAABBiZGgRoAQAAAAAAAAD2stVPrO5ggkAAAAEEEmmZXGcUAAAAAAAAekF2wIIJBIAAAABiQeZGs R1s0SAAAAAAAO+F4RBiZEgAAAAAAwMgaJFd4AAAAAAB7CXOAkAAAAAAAAgxK+TQoAAAAAAA72XhE gAAAAAAAAEGipXaQAAAAAAD9y+0+oAAAAAAAAAGiJXgQAAAAAADki6876AAAAAAAAAQVmGmoJIAA AAJIBtuWimQAAAAAAAABiU6nhoAAAAAABsKW8gAAAAAAAAAgosOqgAAAAAAHuBccAAAAAAAAADjy ho+YAAAAAAA9iLnAAD8z9AAfifsAfOZAAyOPKTjowAAB9Z//xAAvEAABAwMDAwIFAwUAAAAAAAAF AwQGAQIHACBAEBEwMUESExQVMhc1QiEzNDdw/9oACAEBAAEFAv8Ajda9tG5WBAN3WbmNiovMgZ0o OJsCovkd9d9d9+RJMpGYEqsqu51StaVj8jLRwxFZMzlUY4vfUzyGOiyb/KEyfXWzqX230yJM6KRD Lt1VWrpB4y2ZscL3S/ZhG1X7Jxa+kt+o/U3ZiSRqMJtT8eubRdtWWzDIxVrAeKusk3ZzYy2P5N2N 11Wr9i5o8Cdc3r0oH2YaMVeQbi5ZGvHmNNrNm4fkxrX6GPdF10WzTJstayaUdQ4pwakgwOLDtuLk 5ms+w377MVQtNiI9jkiDx0eWzU0T0flhySOelKVrVhiqXvh+N4U9ijDb3/qQNCRKTV02fDvMZGJG oqdxLIBAztWlemL4sDPlraUp0k0jfSeTbMY/Yrck7jx5lHYycy3IidkAhsdlApq1bsh/n7ayhfF1 5X0ZvHQ8lB50zlAqnpuxdO17C2wqWYBQsymT2Wm9YpGrj8Ve+16UHDbLZZGbnSJ0K5ed+nfbPCbw RivY0dOWRKMT4KUhe6y66xaESttJ4h0JEWYgFNJo7lxfUBizeVSpkzbsBe6QQsDJn+TIeOjV1t1b bo1lY6IVEGhp0R1p6HTTMBGJVNjEqe+UGXcgpONPhy6RIg2FAp7P75ZbpNO9VbHcOtjEX8Eij7OS Rk1HygItqBy66KS9s6bPWHTvrKsp+8y7zsXzoaWPTOQSNLpiuDXfN8Urj6cmh5Ee6FGtQKduYuXa PGz4f6UyZkH6S3h48xrcQ1SnanjypDalgvvqLzYzFVj+Y1H0Zuurdf52bJ0QfKJ3pKsB70mShuKm YzVKUpb5cjY2739u3Dx0p8rNJaMgzlooAICIcCbYsRLOHrJ2OJcGHr/T5S4XrqRxILJ2SGEWlpPJ scBxrHvni9lVMj8XOCtKCfPAEqLZk4ucv8zzxh7UdkPi5vQ7hfOnd8CySti7fiZvdUoK87Vm7fO4 wg8awDiZqU+Kf9PbyYadfKyf24uRyX3PMHnxZWtM48U7Wt028+N1KpZr4jpexqMWVvXeefH/APuT bX12U/Lr/On5e38dW+j39oOfuG9b+5//xAAUEQEAAAAAAAAAAAAAAAAAAACg/9oACAEDAQE/AQnf /8QAFBEBAAAAAAAAAAAAAAAAAAAAoP/aAAgBAgEBPwEJ3//EAEYQAAEDAgEGCQcKAwkAAAAAAAEC AwQFEQASITFAQVEQEyAiUmFxgZEGFCMwMmKxFSQzQnKhssHC0SVjkkNQU3BzdIKT8P/aAAgBAQAG PwL/ACccVUqg204kX4gG7h/44Ih0F99PSdkhv8jgipU9+nDpoVxwH3A4RMp0pEuMrQts/wBxOPxT aoSFcVHPR3q7hhbzzinXVm6lqNyTwZs2Ey6W+UE/SNHOh3qIwioRQWlA5D7KtLat2rmK1kz6uRmj g5m+tZ/LCrVMQmzoRHaSm3fp+/AI8oJmbe5gK+Xn7j3U2+GBC8q1JCfqzkN/iSPiMNyYryJEdwXQ 42bhXJpEVR+bIilaB1lVj8Bya64Vgs8c2lKdtwDf4jV6751fj/PV3v25vu5PyK+8fMpws2lSsyHB nHjo8OTR6wFWWlRjrTvB5w/Px5MuouZkTn/RdiLp+N9WcffcSyygXWtZsEjFTqkNNorikpbJHtBK Qm/fbksyWFZDzSwtCtxGIksDJDzKXLdovyKBGvnW84u32QB+rkyqSvTT3eZ9ly6viFasqSxOEaNE Vxkhk5g9oAz9XKjw4rZdkPLCG0jaTiDCvlcQwlu++wtwrfkOpYZRnWtZsBiK1TzxkCClSUO2txil WyiOrMORDpkS3HyHMhJOgdZwWaZBZhIV7XFItldurVNLAbJayXlZZ0JSbm3Xym/KKpMfxB8XiBX9 kjpdp+HAiRV5YjIWbNi11L7AMLao1LXIOx6SrJT/AEjGXU5qlNX5rDfNbT3cNhnOESPNWogULpQ+ 9ZXhiou1JTSpkpSQA2crISm+3rvy8upVBiEn+a4BhqXEeTIjOi7biDcKHr51KeWW25LRQVDZ14cl xnWqs2jOpDAIctvycZ+GQ/VZCX3YxBbp97ZfvHeMAAWA0W4HajMOSNDLIPNaTuHJaerb6GihPzMP ewXOvlv1SeuzLehKfaWrYkYdZgBukR1bWs7tvtfth2rVSbKq8tLmS+04SgJPWb3V44aiRGUx4zSc lttAsEjUUyqDJS5NUpSZzbTdm7jbff2cLMyG8qPJaVdDiDnGEMPKRHrTafTMdP3k9Xw9Q15OViSX WHc0J5w521dC+47OS9PqMhMeM2M5O3qG84Djl49PaPzaNf2es7zwMLfKCJThfaCNiTvPLSqfOYhB Xs8c6E38ccSmuwi5u84GPN49ViPP9BD6SfUVafA5slCEpSro5Swkn7+SzLiPKYktKym1oOcHEOTU KlHhz7ZEhpxYTzht7Dp5aVoUULSbpIOjDDnGp+UmkhMtraFdLsPDJqM93iIjCcpxeApSDHgMk+bM ZWjrPXwORJL5ZaZSHFpAzrF84wxDithmMyjIbQnQBy2JNVYW460jJSUOlObEB2kwH0x3geMeLmUh JH1fzxdJsrYd2GmKmfleAMx4z6VI6lbe/CZ1LlJlMbbaUncRv5G/EmqT15LLQ9kaVnYkY+cr83gp PoojZ5o7d59dEqUVxSFtOAqCT7adqcIVTqkxLyk3CUODK8NOJVQlryI7CMteI0SKyuHTmlFRQV34 07CeBLbaCtxRslKRnOOOko/jEoAyD0BsR6l2mzVLbQrOlxs50HfhyNUIbscBZCFrQcly20HbwIef K1Up1JTKbQm50ZiO+3dfDcqG+iVGcF0OtKykq7+QmlQ3uMp0HNdJzOObT3aPHUGJsJ4syGV5SFDf jiqnNyo4Nwy2nJRwo8pavHKEjPAbXt9/9vVvUtTxjrJC23BsUNF+rEmnzWizKYXkrSeBEWWtb1Dd PpW9PFe8nDUuG+iTGcF0ONquDwOeT9Cf+d6JkhB+i9wHfv1SNXa63kQL5TEVQzvdavd+OLDMPWCu 09jKqUVPp0o0ut/uOFQhLD8NZu5GezpPZuOFRaNBdpsx3M4+tYPFj3evBUSSTpJ1BMWEwuVJUCUt Npuo2Fzm7BgtuoU2saUqFiMNw4EZcuSs81tsXOGp/lCET5+lMfS0129I/di2z1y655ORSTnVLiN/ iQPiNUoCv55T4oI/PCflWmMylJ0LKbKHeM+FIpVOZhhXtFCecrtOnUXqrQSiLUFc52Mczbp6uicO w50dcWS2bLbcTYjUqA9umo+OqcVUo/pUj0chvM4jvwFSK267Dv7CGQlfjims0mAiOt2Zz3TznFWS frHUKGgaTOb/ABat5PMbVOur8An99Q8n0K0ec5XgCfy1byaOzIf/AEahRZgsOLlovfdex1agSeg8 4j+oA/p1BCtyr4bebVlNrSFJO8HVaDC+st1x3ssAP1agliHGdlPK0IaQVH7sUaNUE5E1qIhLqdxt qtNbyr5MLRu5x1B+P/jw1DwIOrVZwH0TKww32JFvjfUKP1pev/1K1ark5z567+M6hQVDa6pPi2oa rIlOfRtNlauwC+HX3DdxxZUo9Z1Cgf7j9J5Q9SODwx3Y/wDb+CV/pK+GO/1A7Mf/xAArEAEAAQMB BwQCAwEBAAAAAAABEQAhMUEQIEBRYXGBMJGhscHRUOHwYPH/2gAIAQEAAT8h/wCIcV135/hpo/hB yrwY7HwF72o0jwq9isYr0HdR7AaE5+dOzqPRvxMIqFQoZ3gpluJm3g1uR1SmPNdrZVc0sstSFK5j S02hsL9uzk0rK2KAcy1LyPJ4bCg1wRwSTQZHU9M1McbZzymNUiVhdPmg3IqCnkWNNwRjoeRfg7mt WFBe7mJu+5Fe4+LdS6GiiafHs1jrwWtTWmw8dnhif4N2+5thUoGkZ6mmCNyTu+dQHZN0DS4iczD8 fiteC12vj2VM1VxSWoohkT7vndUKYWVSNRD3uSOHzufEpNusC62V1i/0zscVHitfV0qKMbZamzQq HqTYcrzCnO7kpvc6ArXz+Ojl8bTS1Bz81cVrNZOHMMI7TuWMgkevAYCoVQRBwsKy+ee5Pj1CWsm6 8VZIMmdrn11indSsYR3cSzkviHNoIhThcybDJcP90wXrGt1uKeSkdwntuc92XaLFRgDLSpheUbiR Mdm9RqvTOltTmORvIINTPjEi9jNd8Xm6D6Gb5rXeziLrnjwb1aPemdYX7CtKAETM7ZmsAI/G8jzb JI5IAgDZOfcyDj7l1d1uD6K7sKwITE6xrFATO8koAGumA6r+2rVXPYkseBVvNw95gFYhmHaux4gB A9CLeghZ1pvLigjAwCVxuGJznZZB8wtR/Sta337JT6XpTvoUHzO4uWfYNtdzWpgzst6BlNAo8EwU oOX1eemCs0dWcBSAQZbeKnCtd3JCB4tKrX/mH3zGtTgJge+wNAamobMbFgp3zVVJL1CzrugiRBBU MfzUlpA9ARz6b57gQZRhGocmO5rWdCbc4oxsALLgmCYANVUA5tcs0ej77A7adWLQU0MKGGFMd6B/ HBIxuM6bdeP71mGKn1eXiUMimpvprReJYWHqqxJhLvPoSxkplHYdsKdYXY2YNmEmzWocTxktgaq1 rH5PvfefEbuKl5+hHecBcvcxJzTfqaonXEnJqeP6GYNDq4qXss9hg2sYLxLsA9qQI4AoMOW19YO0 35vY9DSmSARguibPZoEgfALog2xWtDT0s5KMpcqIxMEgmJBZrSpqBRCK1Tm+9o/twA5OacOmtBoU BSTWDPnauICfC73nLHy5TBsdk07JvTyqawitsfMGq1POSuRyJjzOYkI8mi+aiDpyk6XfJrfWoENS H6JsEiFzix911GMZmFWZ4KKsbGn7gnHIfTJkABYMHqWicCs+mv0zyKdgusQnqrp6x5mpaBvWzp1X JQjTojppRKvAJbhEVohmEfFJ5eG+4GoXVpM69Dq2oYBxnru6H7ZoACBg26+jLFqQS9IkKBSv/sg7 lKUIjyeDU9haVv6cOxXyr8ubLW7y7ZvHp61F6nnSAVeok857LyzwbRoBExKT46x/O5OunrNZRQXH kPtoXOjagrzLg5Xoe1Rn1WoVDIxfGOANSfoWyb0EPXgIuNaVNTpwztOA4oGhy3YzwWta2oPMAPfg LR3GcAjJ4Wr8N+7I9clSQl4aM0O2gkfnhT/C06CfeXtRnn6kWnagdr+/FF5sMylCHhGxSWQn736v VLLfbJaEd1fqJoA8I4pZoEpmJT3n88AQDYHUT/jhXFKPLI+mabt3Gb7fmeFdFIX5pfVddVDJL98B 85vH+Hc3cG4V/a0YdvtX4K1O7T/Piv8AK56+96Hw9f/aAAwDAQACAAMAAAAQAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAgAAEAAAAAAAAAAAAAAkAAAAAAAAAAAAAAAAAAkAAAEkAAAAAAAAAAAAE AAAAAEAgAAAAAAAAAAAkAgAAAAgAAAAAAAAEEAAAAAAAAAgAAAAAAAggAAAEAEAAgggAAAAAkgAg AAAAEAAgAEAAAAAAAAgAAAAAAEAAAEAAAkgAAEgAAgAEAAAgEAAAAAAAEAEEAAAEAAkggAkkggkA gAAAAAEEggkgAEAAkgEAAgAAAAkAAkAAkkAEgAAAAAAAAAAgAggEEgAAAAAAAAAAAEAEAAAEAEEA AAAAAAAkgAgAAAkAgAAAAAAAAAgAAAAAAEgEEAAAAAAAEAkkAAAAAEEAAAAAAAAEAkAAAAAAAggA AAAAAAEgAAAAAAAAEkAAAAAAAAAAAAAAAAAAgAAAAAAAggAAAAAAAAAEkAAAAAgAAAAAAAAAAAkA AAAAEAEgAAAAAAAAAgAAAAAAAEAAAAAAAAAAAAAAAAgAAAAAAAAAAAAkAAAgAAAEAAEAAAAAEAgA AAE//8QAFBEBAAAAAAAAAAAAAAAAAAAAoP/aAAgBAwEBPxAJ3//EABQRAQAAAAAAAAAAAAAAAAAA AKD/2gAIAQIBAT8QCd//xAApEAEBAAIBAwMFAAMAAwAAAAABEQAhMUFRYRAgcTBAgbHwUJGhwdHh /9oACAEBAAE/EP8AB0v+FSac9+2BWtvTx7kU1z5wCpEfP3iyf+svOpPog6NvD3yo3e/u5oFr3xBE Sjz9BAA8XWCQqDPY090qgA1Q3iVgT5Add7KJgoIHygSAFN+VOGvW0iZsmC6iDqH3ELYXriFNOx1d XIO6fi/rDdRNypgBT3Az68BNQSBh1a0piYaPKVEqXq4ipXDR3xEn5MBsuOG8qOlCJtDjRzLRwoIM AHIcND7VA029jLBzsjIw1QA1diYAdxBpNEnHLW34xt9qE/MBH84xslaKRrJ4RB3zm9hLIJvYiaBB OogdzzK+tkO6fInR9s1I9dXLO6GvE1y+0lVcdch0EQ9b7YsK3sA+yvCPzgFhvziWLPOTz76LLlF/ UcB24fE9pF58ls1pggSlWGTsUmmS+wFzQOM+UDe4O3tPVz8uuM1Vhhep575um9fYN1HODwqbwA49 DSkVArrgd3GeBgOskEpESgB2e3i17+s3wg5u1E9kCvGnsJKrx5E/3r29u4Z1mzjjkS+B49K4RfOS cH4ay8I/P1FhZcEaOPjOAcHXeVFt8+pM9nxih60KA4oMZRTlPbAsmfIA6N8roK5oOglA2COwVMe/ rDFU5+VgHBV65WumbsVdGpLUR9hQA89zaESxWaDLPHqiYDaCxTK7vqleXAMUp4HWF3W719NALo7T eAdUH8PtUQWmgUGMIGiIw5+vtp7nV2AqFwXcBEMIhZ5zo+VM6MwErAIqUpQeXaU0JQvL+MOsla+W op1/J6ltcPUWABtXCEXRoKjKyOgdQcgKjQaNhtIaTn6e3qgck9gxlYVa3rRzhpqkHuAaTXvUD9GM 0AX+MjG9e4zQei50DzAjrJ1wL7oZxsRTtYwscYCkAiPb1WondiLwLIXd9KDEfnahQADggegdtniT mS9YRRWaD2bu9TeoedNYuNMGZVX3HnQ43QEq/ACQFxOrpB3NLWpyq3pw1bki50jUIaRwbtAcDgHH 0OhW9HqfQALQ6mV7xeqMS3NSiV6jJ4fm9k5EURoijRTDUuQDBo6sQdpR4LZPP69wo004+rVMAQou gU9FoQRKNPUOcJNZauhK3h9hrYVyWdMogAah3wHQqgqBVwL/AJAoybVsVhDuEcDZcvCfn2LJ5yxo uAfOhfxjXpf6iDeQ6avXANqGn2VV8BcQAt8mIHhfxnyXt1/tYgo61ixUU8YNLgUbMhZZdEQ7qroB 6YqtWvn2dNV9XiP/ACcIo6cTI2LfRghRoE6UHuXGVR9QNiIInCYLLuRQQ1uldBXITExZfGLCrDu5 chkVQIbBJtA64B7rYGyZowWzhoriwNhy3nIBH5HQW6J8LN7KT1UjgFVeLVXe8m8hR6npoPLeC1sn T0ZnBmtZnEq7l3zxACOxjgEKhqUPRCuECgi8EdPnFSNhNG+WgnVQdTB8SaVzS0gVf9yYAAcY8Zqy wiuVMXYoCLwidsHYFXQucxwBz0jW6u0bim+wVU5yXCD5+gt/Teih4hoEseTCJelwVL6RoEjca8De vQB1SA7ubsPoEBgaS8pudPolhLjaAbVdQzkYS4Sr9AhZ1eTC7dYocs9rszgYOMoXAADoUQRF4YkU cHSpPIVs8/jHkDe3nGF8+AhyDNbdAKmLMma+kqgImnkTpg0PfAJppigEa8EyHFTKTcMM04ojVP15 jiXveLQeEdIpi8dan0ctfJ3l9Gdgw6wr4HV2tkKwBUOcm8XHHJzigV1jpefxigbivoBBRU1MRtHT 95SJInfK+J/ZCPmE+AaMcoMJIbNGw4BBOcAtk/GO7KG3yKdRiegqMZslCwOVU0iJyIjExnUd/vIM WPKI0uAWjXRrFRKq1fsq6FzVtT4JPUggoUHRjgLJg8A6B0OPXT5+gI2NmBV3QCOYOtSRWNwzm1E6 eiK7nMcuBQp19QAMJ/XUPBkUuCO6UcNXezWaqu1Xr9g/V7TkEWhALFlbBCN2AI/OWRzz36OANqAN qGT9mnWoAQqt6PBpgUwIBAOx63Q7/QVDRjswnR5yCFO3fF0fWxpSneu6hyY1M2IRPs7kqW9Gj8iM 381osyg0NcKMhkYMAONgSsECsC+syKvxx9Pda1iWk/8AuEMW8O5AY6FQcJU7xtcVALM34eR5Eomx T0j9gD4OOSFPqWdMNFPDqTJvAhzfqTqlcUq2G9PGbhQUVY8rYGt8Ll8QXvXF88Z3U4pbINoMJw1r 7DWmCHh//Hogh56ecMLCOmFiJ9brg1ACdunjHSUvXWAWDhl46vSv/e/2D5gXeqkPyg/ONmsILydM hfsZzr8dMLTBTqbMCl/2YX/Z9hUia6kF0N7DhY937SY0AR5SvQv70xQx/f1kmLSEhygL+s4qWzCE 8IH7WOyfd14eUvniXjScY8/Tri1Z6zvMXPwSv+sEiFcnqFKADNW/aIo1+DJqDCtu1nmP9erOrd4+ iMeB+cSmz6iUFSbi55h/A4ARWHVv2nFAt1TFsNMAE5OnwP0817Zhjr4N/sP4+11CsBxJadiV+m2g /wC+0SBBEoor+L+1fAfDegPwsSq9nLLflXvC3x9w7xP3v1nP/W30MP7/ADj/ADdmc34/T0i/3+fo f0vOf//Z --Apple-Mail=_E6339B48-7203-4EEF-A932-BD01CBE4C199-- --Apple-Mail=_77A84F75-7448-4EDF-BC8E-421C482B1194-- From nobody Tue Feb 18 17:50:33 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 869DF1A051E for ; Tue, 18 Feb 2014 17:50:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mEJAZ_tUS6OA for ; Tue, 18 Feb 2014 17:50:24 -0800 (PST) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id CD5E81A042B for ; Tue, 18 Feb 2014 17:50:24 -0800 (PST) Received: by mail-pa0-f52.google.com with SMTP id bj1so17486871pad.25 for ; Tue, 18 Feb 2014 17:50:21 -0800 (PST) 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=pUmIzfdM65VfoVXuXb0RDOvuyScH76cd9A6w85Wb0PE=; b=TLBPlcsI00sZQpeKPC9f05+BiZB0eLXeXPVzimjKR34HVdeDS1ZHMQhl+BE1Klezxo 9oKRGWG4o1JHYZ/KAVWmNGuH5lPSmbTKwCQOcrESFP9T+V8TntRuTKZSy6wy1PXViS3F S87+1RR0FClQLuoIFctflSzekK9CJVconUeOkUcU0HBAnaINh0omnXd4DRWjLMKfc35N XLyQFhNLyDGKlm9zCAFiTLSkvdhoaDuAfMIJ3YTxYvZLTIlTHovrLFoHYFjDtdbTejuT ylw5R3IdP834qn2b076iHztWY6QMzMp2OUJFs3FJhkPZsddJGY4SdVws1v2cvw/Xn6pk jVTA== X-Received: by 10.66.182.199 with SMTP id eg7mr18825863pac.135.1392774621862; Tue, 18 Feb 2014 17:50:21 -0800 (PST) Received: from [130.216.38.108] (sc-cs-567-laptop.cs.auckland.ac.nz. [130.216.38.108]) by mx.google.com with ESMTPSA id ei4sm60425424pbb.42.2014.02.18.17.50.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 18 Feb 2014 17:50:21 -0800 (PST) Message-ID: <53040DE2.60003@gmail.com> Date: Wed, 19 Feb 2014 14:50:26 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Tim Chown References: <20140214181753.13350.92327.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/VFm4Mac_7d3js8mCHU2xiUeMf7E Cc: homenet@ietf.org Subject: Re: [homenet] New arch text: draft-ietf-homenet-arch-12.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 01:50:30 -0000 "Some specific transition technologies which may be deployed by the homenet's ISP are discussed in [RFC1918]." That gave me a good laugh. Regards Brian On 15/02/2014 07:21, Tim Chown wrote: > Hi, > > For info, this draft is intended to address any remaining IESG comments. Emails have been sent to the ADs in question with the chairs copied. We hope that any remaining DISCUSSes can be cleared before London. > > Tim > > On 14 Feb 2014, at 18:17, internet-drafts@ietf.org wrote: > >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Home Networking Working Group of the IETF. >> >> Title : IPv6 Home Networking Architecture Principles >> Authors : Tim Chown >> Jari Arkko >> Anders Brandt >> Ole Troan >> Jason Weil >> Filename : draft-ietf-homenet-arch-12.txt >> Pages : 52 >> Date : 2014-02-14 >> >> Abstract: >> This text describes evolving networking technology within residential >> home networks with increasing numbers of devices and a trend towards >> increased internal routing. The goal of this document is to define a >> general architecture for IPv6-based home networking, describing the >> associated principles, considerations and requirements. The text >> briefly highlights specific implications of the introduction of IPv6 >> for home networking, discusses the elements of the architecture, and >> suggests how standard IPv6 mechanisms and addressing can be employed >> in home networking. The architecture describes the need for specific >> protocol extensions for certain additional functionality. It is >> assumed that the IPv6 home network is not actively managed, and runs >> as an IPv6-only or dual-stack network. There are no recommendations >> in this text for the IPv4 part of the network. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-homenet-arch/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-homenet-arch-12 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-arch-12 > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > From nobody Wed Feb 19 00:27:38 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDE561A0389 for ; Wed, 19 Feb 2014 00:27:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.769 X-Spam-Level: X-Spam-Status: No, score=-1.769 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8jCqhY5X2HK for ; Wed, 19 Feb 2014 00:27:33 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 6BBA21A0080 for ; Wed, 19 Feb 2014 00:27:33 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s1J8RNhm004288; Wed, 19 Feb 2014 08:27:23 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk s1J8RNhm004288 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1392798443; bh=kJkv+EJ435JGDJpgkrRGpLDU5xc=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=QSyD3tBrxSMwG1xFGrVhEwyitVxEaCsLzPuuLOK9jJzEmdnpNkraCeJr+4yF1gfne aAUGdFqJbJbcfXZdZgxdKgd894YPY6e5mOpOvBUgFT60PSffh0cwXTpIhB37SNOb3n 0DqvcXWXvtCcAHuus3prqiETbR7ZreHuLV2zOm2s= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id q1I8RN09596201892d ret-id none; Wed, 19 Feb 2014 08:27:23 +0000 Received: from [192.168.1.109] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s1J8Q1FK007930 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 19 Feb 2014 08:26:02 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Tim Chown In-Reply-To: <53040DE2.60003@gmail.com> Date: Wed, 19 Feb 2014 08:26:01 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20140214181753.13350.92327.idtracker@ietfa.amsl.com> <53040DE2.60003@gmail.com> <850BC545-0BDA-40A8-A8E5-689FF940566B@ecs.soton.ac.uk> To: Brian E Carpenter X-Mailer: Apple Mail (2.1827) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=q1I8RN095962018900; tid=q1I8RN09596201892d; client=relay,ipv6; mail=; rcpt=; nrcpt=2:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: s1J8RNhm004288 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/oMSM82lXP2R_quZoq9bbL-BDPwc Cc: "homenet@ietf.org Group" Subject: Re: [homenet] New arch text: draft-ietf-homenet-arch-12.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 08:27:37 -0000 On 19 Feb 2014, at 01:50, Brian E Carpenter = wrote: > "Some specific transition technologies which may be deployed by the=09 > homenet's ISP are discussed in [RFC1918]." Whoops. I smell a cut and paste slip when adding a ref to the recently = published RFC7084! > That gave me a good laugh. It could be interesting to deliberately add such things to test who's = really read a give document thoroughly :) Tim >=20 > Regards > Brian >=20 >=20 > On 15/02/2014 07:21, Tim Chown wrote: >> Hi, >>=20 >> For info, this draft is intended to address any remaining IESG = comments. Emails have been sent to the ADs in question with the chairs = copied. We hope that any remaining DISCUSSes can be cleared before = London. >>=20 >> Tim >>=20 >> On 14 Feb 2014, at 18:17, internet-drafts@ietf.org wrote: >>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>> This draft is a work item of the Home Networking Working Group of = the IETF. >>>=20 >>> Title : IPv6 Home Networking Architecture Principles >>> Authors : Tim Chown >>> Jari Arkko >>> Anders Brandt >>> Ole Troan >>> Jason Weil >>> Filename : draft-ietf-homenet-arch-12.txt >>> Pages : 52 >>> Date : 2014-02-14 >>>=20 >>> Abstract: >>> This text describes evolving networking technology within = residential >>> home networks with increasing numbers of devices and a trend = towards >>> increased internal routing. The goal of this document is to define = a >>> general architecture for IPv6-based home networking, describing the >>> associated principles, considerations and requirements. The text >>> briefly highlights specific implications of the introduction of = IPv6 >>> for home networking, discusses the elements of the architecture, = and >>> suggests how standard IPv6 mechanisms and addressing can be = employed >>> in home networking. The architecture describes the need for = specific >>> protocol extensions for certain additional functionality. It is >>> assumed that the IPv6 home network is not actively managed, and = runs >>> as an IPv6-only or dual-stack network. There are no = recommendations >>> in this text for the IPv4 part of the network. >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-homenet-arch/ >>>=20 >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-homenet-arch-12 >>>=20 >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-homenet-arch-12 >>=20 >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet >>=20 From nobody Thu Feb 20 06:26:56 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D04C01A0199 for ; Thu, 20 Feb 2014 06:26:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kKOozvCIJ8RN for ; Thu, 20 Feb 2014 06:26:53 -0800 (PST) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 687D71A018C for ; Thu, 20 Feb 2014 06:26:53 -0800 (PST) Received: by mail-we0-f179.google.com with SMTP id q58so1547970wes.10 for ; Thu, 20 Feb 2014 06:26:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=iqQkjkIFTj/h0bmLj8Khb8D0nqFVNArd7zg8pwBqFYc=; b=GSUigCTCRm7jeJqWxueVygdszNa8kmWViKEn/uauR6ZZ5sQ7CAUGLZgI7ive0aDwg9 rFPjLquzK6ez/whYv09W2T/YXnqeNiyjJe70rDEwE9caqXKZ8EtV+bk544aPlDYyXJQw xXEL2KrGedqPW455ezR3CNsaDV4ka62T6lE7PL9VGsHDAbn8+Z+vM4lGI5fpvGMDFniJ S/aTJayrF1UScF0Tesbrdk0oYnv1lOH6gIbJ3+nDdC4iFApZ9MLxr9amcJT31Gozjbf0 TXV48pAOfMGQCkg7AcBjCJcKYaS1vg7DyfrLRBbKdkuFSL14iGZ0ZsQR9TqPzrPxFgKt 8poA== MIME-Version: 1.0 X-Received: by 10.194.87.5 with SMTP id t5mr2367254wjz.68.1392906409356; Thu, 20 Feb 2014 06:26:49 -0800 (PST) Received: by 10.194.171.129 with HTTP; Thu, 20 Feb 2014 06:26:49 -0800 (PST) Date: Thu, 20 Feb 2014 15:26:49 +0100 Message-ID: From: Daniel Migault To: "homenet@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/d9YcCP5hnnOh9GSYxYbCLdMSVk4 Subject: [homenet] Zeroconf naming architecture X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 14:26:56 -0000 Hi, During the IETF in Vancouver most questions concerned the zeroconf aspect of the homenet naming architecture [1]. I would like to clarify what zeroconf could mean. I expect your feed backs, comments and thoughts for improving it. I. Small recap about the drafts: a) draft-mglt-homenet-front-end-naming-delegation [1]: describes DNS zone the CPE would publish on the Internet is outsource to a third party. The goal is to avoid exposing the CPE to resource exhaustion and DNSSEC misconfiguration. Our motivation is to properly re-use DNS mechanisms to ease naming configurations on CPE and eventually provide zeroconf. The draft points out configuration parameters for the architecture. b) draft-mglt-homenet-naming-architecture-dhc-options [2]: describes the DHCP options to automatically set the homenet naming architecture. II What is Zero conf? Suppose the information is provided by the DHCP. - a) It can be completely Zeroconf, if the end user accepts "user.isp" provided by the ISP as the domain name for its homenet. In this case, there is no configuration at all. - b) Similarly, if the end user and the ISP have agreed for "myhomenet.isp", we can consider this as Zeroconf. In this case a regular user does not have to configure anthing. - c) If the end user wants "myhomenet.com". One way is that "myhomenet.com" is redirected to the "user.isp". In this way the configuration is performed by the registrar of "myhomenet.com" and no configuration is performed on the CPE. We may consider this as zeroconf too as we can hardly provide less configuration. In any case, no one can guess the user wants "myhomenet.com" and register for him. - d) Another way to do so is that the end user configures the informations stored in the DHCP options. This can be done once for all via a web interface and may require multiple parameters to register. In this case, the zone is not anymore hosted by the ISP. This case is also a configure-once-for-all. This may be also considered zeroconf? [1] http://www.ietf.org/id/draft-mglt-homenet-front-end-naming-delegation-03.txt [2] http://www.ietf.org/internet-drafts/draft-mglt-homenet-naming-architecture-dhc-options-01.txt ---------- Forwarded message ---------- From: Daniel Migault Date: Thu, Feb 13, 2014 at 5:37 PM Subject: draft-mglt-homenet-naming-architecture-dhc-options-01 To: "homenet@ietf.org" Hi, Please find the new version of the draft draft-mglt-homenet-naming-architecture-dhc-options-01. It defines DHCP Options to configure the Homenet naming architecture. Feel free to comment! BR, Daniel A new version of I-D, draft-mglt-homenet-naming-architecture-dhc-options-01.txt has been successfully submitted by Daniel Migault and posted to the IETF repository. Name: draft-mglt-homenet-naming-architecture-dhc-options Revision: 01 Title: DHCP Options for Homenet Naming Architecture Document date: 2014-02-13 Group: Individual Submission Pages: 18 URL: http://www.ietf.org/internet-drafts/draft-mglt-homenet-naming-architecture-dhc-options-01.txt Status: https://datatracker.ietf.org/doc/draft-mglt-homenet-naming-architecture-dhc-options/ Htmlized: http://tools.ietf.org/html/draft-mglt-homenet-naming-architecture-dhc-options-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-mglt-homenet-naming-architecture-dhc-options-01 Abstract: The home network naming architecture requires a complex naming configuration on the CPE. This configuration MAY not be handled easily by the average end user. Furthermore, such misconfiguration MAY result in making home network unreachable. This document proposes a DHCP options that provide the CPE all necessary parameters to set up the home network naming architecture. First, this DHCP options provide automatic configuration and avoid most end users' misconfiguration. Most average end users may not require specific configuration, and their ISP default configuration MAY fully address their needs. In that case, the naming homenet architecture configuration will be completely transparent to the end users. Then, saving naming configuration outside the CPE, makes it resilient to change of CPE or CPE upgrades. Such configuration may also be configured by the end user, via the customer area of their ISP. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 From nobody Thu Feb 27 00:24:41 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D11CB1A00AF for ; Thu, 27 Feb 2014 00:24:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.846 X-Spam-Level: X-Spam-Status: No, score=-4.846 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1XUjmdm9p1Lh for ; Thu, 27 Feb 2014 00:24:38 -0800 (PST) Received: from mx1.nominet.org.uk (mail.nominet.org.uk [213.248.242.48]) by ietfa.amsl.com (Postfix) with ESMTP id 0FE571A002A for ; Thu, 27 Feb 2014 00:24:37 -0800 (PST) DomainKey-Signature: s=main2.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:X-IPAS-Result:Received:Received:From:To: Subject:Thread-Topic:Thread-Index:Date:Message-ID: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:x-originating-ip:Content-Type: MIME-Version; b=PX7m7rLoS2xJ4jXhlUxYsY0p1DV0aln9a69cVihPFeqZCkuYeHOYhmn0 lebKEDRTJ5kT0q/UnTMGEB3sqPqNtOhDVsaVFnl6mxGNyZ7jrsE81SDRw AO/cIBPkhJKJwOylKzCSyABGOhwJiXKGAVhrIJm6phsuo91JCMBUPZz+F 9AbwLESd2hRkG+srmK6shzQ2f59TOxxrPDoLTod0ILR226jXfUwtmSwG6 6ga1a/2ewCFB0Rmc/PXA8y5Gv9O/6; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=@nominet.org.uk; q=dns/txt; s=main2.dkim.nominet.selector; t=1393489477; x=1425025477; h=from:to:subject:date:message-id:mime-version; bh=IFkdHckTQYcobBwnwSRRDxv20b1H6rxndsav5sqDKPY=; b=Kq20wmVGc5AUNnyf8SdZ8tNYp7oShIXoaO0E0UscAI1HqX0UNMz9PLUe UGNODzT1n+X8l9Zzw1GpoAV33M82InyqTzaYwEKO6xhE4jFu0KJUbZwmU EPWWkYJKsxRx3HYxnR6srqdWARLqo8lUf5bIu/6fsowHeLB/MGDMd7ZFJ 9ehVtXkKnrLE7GZgk/EqxdLDanlKjDhQssAsObbMs71sz5DDc5vr45nmO gXIG1SVLoXMXSSnVDuHI4GkAS0jmI; X-IronPort-AV: E=Sophos;i="4.97,553,1389744000"; d="scan'208,217";a="7967814" X-IPAS-Result: Ag0GAAT1DlPV+MWR/2dsb2JhbABagmUhO1e4QYhHgRUWdIIcCwVTOAELAR5WJwQbAYdxAwmaArA2jiOCZg9mgRQEqmGDLYIq Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx1.nominet.org.uk with ESMTP; 27 Feb 2014 08:24:35 +0000 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%17]) with mapi id 14.02.0318.004; Thu, 27 Feb 2014 08:24:35 +0000 From: Ray Bellis To: "homenet@ietf.org Group" Thread-Topic: Draft Session Agenda Thread-Index: AQHPM5VYIvKadBPJN0uYnX0dO+Gb4w== Date: Thu, 27 Feb 2014 08:24:34 +0000 Message-ID: <18C8BE29C547CC4DBBCF3C4F0B8EC1780B526B@wds-exc1.okna.nominet.org.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.1] Content-Type: multipart/alternative; boundary="_000_18C8BE29C547CC4DBBCF3C4F0B8EC1780B526Bwdsexc1oknanomine_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/C02BYq_S-J_MXg_xUapAkjQbV0U Subject: [homenet] Draft Session Agenda X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 08:24:40 -0000 --_000_18C8BE29C547CC4DBBCF3C4F0B8EC1780B526Bwdsexc1oknanomine_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable With apologies for the delay caused by both us chairs managing to be on vac= ation at the same time, please find the draft agenda for next Tuesday's ses= sion at thanks, Ray and Mark --_000_18C8BE29C547CC4DBBCF3C4F0B8EC1780B526Bwdsexc1oknanomine_ Content-Type: text/html; charset="us-ascii" Content-ID: <125F99BE30CF904490BB17436AEEF39F@okna.nominet.org.uk> Content-Transfer-Encoding: quoted-printable With apologies for the delay caused by both us chairs managing to be on vac= ation at the same time, please find the draft agenda for next Tuesday's ses= sion at <http://www.ietf.org/proceedings/89/agenda/agenda-89-homenet>= ;

thanks,

Ray and Mark

--_000_18C8BE29C547CC4DBBCF3C4F0B8EC1780B526Bwdsexc1oknanomine_--