From nobody Wed Apr 2 14:31: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 7B0831A03EA for ; Wed, 2 Apr 2014 14:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 MYPzxyERCXNP for ; Wed, 2 Apr 2014 14:31:02 -0700 (PDT) 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 26DDC1A03DC for ; Wed, 2 Apr 2014 14:31:02 -0700 (PDT) Received: by mail-qc0-f182.google.com with SMTP id e16so925558qcx.27 for ; Wed, 02 Apr 2014 14:30:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version; bh=DVrsBM7/Sl4tPl2SnOR4bPwACzLjlge1i6XiCqczJt8=; b=jCnVpTPArlQpDR/tTa+tTBv+m7cjHFV4OSnvP0omDXpEUswULIcmoeb8gcXnwuhzXc /BuDuG3xHjwK4g9JFO+NvBKPMTC1+xSb5tAKhAMS1ooBk5qzCyGRUu6od4NBbGbhYGtO i9aoh/YoCy9USt0YeT99DPpz7+uwJT3AdQB+J6mWYwze8lgfhEQ4tnhtRUTffvBgoOLU FUrrJvwNiZlqe40+LTH6AL40JdQVX1cm3gsEfkZzEupVOU+lVVDY9XwaNAMZfsqYJpeb y2hnFU/1Bwb0wZyIPoXp1Y0iimIFNZKSqOvPJAFM62LEoUiqauz0rPpzyB4OKUCj2NdQ Rb9g== X-Received: by 10.224.132.5 with SMTP id z5mr3208838qas.101.1396474257870; Wed, 02 Apr 2014 14:30:57 -0700 (PDT) Received: from [10.30.20.15] (pool-173-79-6-58.washdc.fios.verizon.net. [173.79.6.58]) by mx.google.com with ESMTPSA id g92sm4185990qge.7.2014.04.02.14.30.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 02 Apr 2014 14:30:57 -0700 (PDT) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 2 Apr 2014 17:30:56 -0400 Message-Id: To: homenet@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/E7-GEfkc8fy5O0twlgbxgmQzz2E Subject: Re: [homenet] [dnssd] IETF-89 WG meeting minutes 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, 02 Apr 2014 21:31:07 -0000 I concur with Tom Pusateri, Markus Stenberg, Ted Lemon, and others: - A layer-2 solution is not deployable in the full range of HomeNet environments. - Many link layers do not use any form of IEEE 802. So RBRIDGE and TRILL and similar are not deployable over many applicable link layers. - We need a solution that is agnostic to the type of link layer. - Further, we have a range of on-the-shelf IETF security mechanisms that operate at Layer-3 and higher. There is no security magic to a Layer-2-only approach to HomeNet. Bottom Line: Not all links are (wired, wireless) Ethernet or based on IEEE 802.* Yours, Ran From nobody Thu Apr 3 16:52: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 D16361A03BE; Thu, 3 Apr 2014 16:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 T2Sn9S_gRo-h; Thu, 3 Apr 2014 16:52:07 -0700 (PDT) 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 DE8C71A03BB; Thu, 3 Apr 2014 16:52:06 -0700 (PDT) Received: by mail-pa0-f49.google.com with SMTP id lj1so2582766pab.22 for ; Thu, 03 Apr 2014 16:52:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xVZVhnLX1Hmb58b73d5BvbbI7xy9GChI+AHUzBVFKwA=; b=cFXkVERBSIISYMNmxCaQbmUxRYKNIwix9SbTpOOLl+DZs+Uy8ZpW3BXZqlkgU91WDX te0Uw+0z4K5O39Uaw74Gbdn6pqNQprnrDyC0fCbpO4lGwdhR/bkd7FOXWP95BCHWeY8x m711Kg8FKLs9IAq3B/siBnx+qEx19FNohC7lw/HER1Xz3HYwDOujc0bxo3mZ9npe8f3+ ji//BjIqCLTrLVFtW4r3VOrAoK8kyMwOmmTvNBja/L+y2blqBD9lELc1AfVWGGzQhjm2 BWxOzOR8M7n6TVbLvQbTvRJVMLHvuDzQAJNTPtNRyZSmMSPN/awwnnVQ5iSNubb0O2W9 53XA== X-Received: by 10.66.163.138 with SMTP id yi10mr10807030pab.95.1396569122664; Thu, 03 Apr 2014 16:52:02 -0700 (PDT) Received: from [192.168.2.242] (c-67-188-1-12.hsd1.ca.comcast.net. [67.188.1.12]) by mx.google.com with ESMTPSA id f5sm31644149pat.11.2014.04.03.16.52.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 03 Apr 2014 16:52:01 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Content-Type: text/plain; charset=us-ascii From: Douglas Otis In-Reply-To: Date: Thu, 3 Apr 2014 16:52:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <64E9ED15-A94D-4D80-9447-80C1E217E19A@gmail.com> References: To: RJ Atkinson X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/Q19eJM36zY2hY60E1hgLX-iqK5E Cc: homenet@ietf.org, dnssd@ietf.org Subject: Re: [homenet] [dnssd] IETF-89 WG meeting minutes 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, 03 Apr 2014 23:52:15 -0000 On Apr 2, 2014, at 2:30 PM, RJ Atkinson wrote: >=20 > I concur with Tom Pusateri, Markus Stenberg, Ted Lemon, and others: > - A layer-2 solution is not deployable in the full range of HomeNet > environments. > - Many link layers do not use any form of IEEE 802. So RBRIDGE and > TRILL and similar are not deployable over many applicable link = layers. > - We need a solution that is agnostic to the type of link layer. > - Further, we have a range of on-the-shelf IETF security mechanisms > that operate at Layer-3 and higher. There is no security magic > to a Layer-2-only approach to HomeNet. >=20 > Bottom Line: > Not all links are (wired, wireless) Ethernet or based on IEEE 802.* Dear Ran, Of course home networks may involve networking protocols such as Zigbee, = Z-Wave, HomePlug/IEEE 1901, ITU-T G.9972 that might not be suitable = candidates for TRILL extensions. TRILL was proposed as a means to = extend the functional use of AppleTVs that impose HDCP requirements. = Making adjacent network multicast traffic visible through automated = processes of publishing translated routable addresses in local DNS = profoundly and negatively changes home network security. While mDNS = does not offer enhanced security, it does not also expose devices to = threats from other networks and prohibit use of link-local addressing. Most mDNS related problems can be addressed through the use of TRILL = with specific service filters without introducing a wide array of = security exposures. There are many home devices that implement some = level of home automation using an OS that can not be updated by their = owners. The proposed homenet using the mDNS to DNS proxy will make = these devices visible to browsers for example and significantly = challenge the effectiveness of existing firewall strategies. In an = ideal world, all devices should be secure when exposed to the Internet. = Our world is not ideal. Please consider the security aspects, and how we might be able to aid = deployment (even in the form of a BCP). Regards, Douglas Otis= From nobody Fri Apr 4 06:10:45 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 6425E1A0180 for ; Fri, 4 Apr 2014 06:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 CXYNCQqKTaPX for ; Fri, 4 Apr 2014 06:10:37 -0700 (PDT) Received: from nm3-vm3.access.bullet.mail.gq1.yahoo.com (nm3-vm3.access.bullet.mail.gq1.yahoo.com [216.39.63.61]) by ietfa.amsl.com (Postfix) with ESMTP id 322141A017D for ; Fri, 4 Apr 2014 06:10:37 -0700 (PDT) Received: from [216.39.60.169] by nm3.access.bullet.mail.gq1.yahoo.com with NNFMP; 04 Apr 2014 13:10:32 -0000 Received: from [67.195.23.145] by tm5.access.bullet.mail.gq1.yahoo.com with NNFMP; 04 Apr 2014 13:10:32 -0000 Received: from [127.0.0.1] by smtp117.sbc.mail.gq1.yahoo.com with NNFMP; 04 Apr 2014 13:10:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1396617032; bh=+ENaiUu+fBS168A4RZj2brMgfmWgN/q71uzfGIMqUg8=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:References:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=Xd1MiPbFrbi7jiXF512SpJ2+FQWxRjaRVwY0Ygg1d8/e06zbCRRDFa5CiYis1XQvzyOxQcJJSnEkiFixIgdbeQRldxbmjr/837+62Ul4O52/Q+DkxTAGS8biXWGI7uYFhRjp97wtftHWVrSB4yj7klHvYpV90MHDu9+IGhc6NjA= X-Yahoo-Newman-Id: 548094.81081.bm@smtp117.sbc.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: SICEkz8VM1mtyzpMRLjKwuSlUXYpqqT0fsYslENzCgi39TD eELZXss8rm_v9oknScWXhUragFEfP26XaXsBx.QWYvALjA7XwxZ1NwI.dYJt UuhcDraq9olx.cSiMFw2w5HRZIdgcR7E4MNXwjywuptqE.CmvgBeyJAsXadh WxfBvSQ3Nid4aItqdV474gFoG_AJqIWqCTcwJ8MLcnqH7l0atn4esuiKr2Hv OI64jp3gv5jDYQZ2ySwATLz2g3Bkx2_4zJhR05rkTtz5XY1RbhXv_55x3KjE vk6uFsBN7Nfkdh7vkKaXdbcsf8wcWMSR..AcgE0qJKflH8LFgOLZhiG6dIln COuZKUOUmXqPugH6RhQwOulzByjnyx.rK.x6XbdDfwQ_Z9JaeUruwghZnnWp muHaL2MAo5obQ.GNsXiU5lGQ2bsir3YPfY3aoWLAdHATgSJquHSvqe_iyztx CQBIJNfCVMelPFkeSGvC5bkenbUL7jkMcPLMYJ_9wpFA2_3w9Bc6Ex7jnUjF Qc9viOfqH_7QUof5iqW2sOMYE1ZfqyEa5tIA- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-Rocket-Received: from [10.0.0.4] (d.sturek@108.225.228.32 with plain [67.195.15.5]) by smtp117.sbc.mail.gq1.yahoo.com with SMTP; 04 Apr 2014 13:10:32 +0000 UTC User-Agent: Microsoft-MacOutlook/14.3.9.131030 Date: Fri, 04 Apr 2014 06:10:27 -0700 From: Don Sturek To: Douglas Otis , RJ Atkinson Message-ID: Thread-Topic: [homenet] [dnssd] IETF-89 WG meeting minutes References: <64E9ED15-A94D-4D80-9447-80C1E217E19A@gmail.com> In-Reply-To: <64E9ED15-A94D-4D80-9447-80C1E217E19A@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/25y8SPOVzvPlUCkO3HEnFpgfFFc Cc: homenet@ietf.org, dnssd@ietf.org Subject: Re: [homenet] [dnssd] IETF-89 WG meeting minutes 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, 04 Apr 2014 13:10:41 -0000 Hi Douglas, As one who follows the WG and having a keen interest in homenet solutions, I fail to see how TRILL addresses the homenet problem set. Producing a flat L2 architecture and then trying to set up specific service filters to contain the traffic seems like an L3 problem to me. Claiming that L3 does not address "security threats" is not a reason to use TRILL since I would imagine setting "specific service filters" in TRILL would have the same issues (and without the existing IETF L3 security solutions we already have) Don On 4/3/14 4:52 PM, "Douglas Otis" wrote: > >On Apr 2, 2014, at 2:30 PM, RJ Atkinson wrote: > >> >> I concur with Tom Pusateri, Markus Stenberg, Ted Lemon, and others: >> - A layer-2 solution is not deployable in the full range of HomeNet >> environments. >> - Many link layers do not use any form of IEEE 802. So RBRIDGE and >> TRILL and similar are not deployable over many applicable link >>layers. >> - We need a solution that is agnostic to the type of link layer. >> - Further, we have a range of on-the-shelf IETF security mechanisms >> that operate at Layer-3 and higher. There is no security magic >> to a Layer-2-only approach to HomeNet. >> >> Bottom Line: >> Not all links are (wired, wireless) Ethernet or based on IEEE 802.* > >Dear Ran, > >Of course home networks may involve networking protocols such as Zigbee, >Z-Wave, HomePlug/IEEE 1901, ITU-T G.9972 that might not be suitable >candidates for TRILL extensions. TRILL was proposed as a means to extend >the functional use of AppleTVs that impose HDCP requirements. Making >adjacent network multicast traffic visible through automated processes of >publishing translated routable addresses in local DNS profoundly and >negatively changes home network security. While mDNS does not offer >enhanced security, it does not also expose devices to threats from other >networks and prohibit use of link-local addressing. > >Most mDNS related problems can be addressed through the use of TRILL with >specific service filters without introducing a wide array of security >exposures. There are many home devices that implement some level of home >automation using an OS that can not be updated by their owners. The >proposed homenet using the mDNS to DNS proxy will make these devices >visible to browsers for example and significantly challenge the >effectiveness of existing firewall strategies. In an ideal world, all >devices should be secure when exposed to the Internet. Our world is not >ideal. > >Please consider the security aspects, and how we might be able to aid >deployment (even in the form of a BCP). > >Regards, >Douglas Otis >_______________________________________________ >homenet mailing list >homenet@ietf.org >https://www.ietf.org/mailman/listinfo/homenet From nobody Fri Apr 4 08:08: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 603711A01C4; Fri, 4 Apr 2014 08:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 8QIRHfprob8E; Fri, 4 Apr 2014 08:08:35 -0700 (PDT) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id E49921A0191; Fri, 4 Apr 2014 08:08:34 -0700 (PDT) Received: by mail-pd0-f174.google.com with SMTP id y13so3421892pdi.5 for ; Fri, 04 Apr 2014 08:08:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=32PYjuUsqdHv1vQvHux2X2NSNANJ7my4uLIajA5PcNs=; b=0u2RRGwfr06CDi0FdkmZV3RY0I50pCIqo6qJymlUKXr3bK3VOcSH0ameQofiV+Iusj DZafSOxxEZIX0qpRZZD5g+wbKV1BLd7ZLqLfxc/hMdqGhsIFkmnNr8gY0akVJKssW60n Q4r5KO0nOzpiMPEjZATps1AhD/iihKbtzb8oSEJXjA2+0fWdGBTUpB486/7gIr42+KDH 2DdLmUmm8MQN+eKgwA1XJZQ1lutpPPQCguvE1cuqVXmEMxmNURWkMt/Xava7eHjIbaUY aeQX+FzBxs7HGZflFcUaQh7KdqD4bLutLvX/BKRCq5cl3UVFuvWXjq+pKQ09sCZs37/d Z/HQ== X-Received: by 10.66.148.134 with SMTP id ts6mr15418911pab.113.1396624110394; Fri, 04 Apr 2014 08:08:30 -0700 (PDT) Received: from ?IPv6:2601:9:7680:68e:11d3:a660:bc1b:dc68? ([2601:9:7680:68e:11d3:a660:bc1b:dc68]) by mx.google.com with ESMTPSA id kl1sm18360240pbd.73.2014.04.04.08.08.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 04 Apr 2014 08:08:29 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_70C649D2-D5C8-42C5-9441-B34BBBBBC982" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Douglas Otis In-Reply-To: Date: Fri, 4 Apr 2014 08:08:20 -0700 Message-Id: <4DBFF820-72EE-4369-9837-AE15F81E5410@gmail.com> References: <64E9ED15-A94D-4D80-9447-80C1E217E19A@gmail.com> To: Don Sturek X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/n89gWdlq21gmOwjsT_eku9KNi2E Cc: homenet@ietf.org, dnssd@ietf.org Subject: Re: [homenet] [dnssd] IETF-89 WG meeting minutes 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, 04 Apr 2014 15:08:41 -0000 --Apple-Mail=_70C649D2-D5C8-42C5-9441-B34BBBBBC982 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 4, 2014, at 6:10 AM, Don Sturek wrote: > Hi Douglas, >=20 > As one who follows the WG and having a keen interest in homenet = solutions, > I fail to see how TRILL addresses the homenet problem set. >=20 > Producing a flat L2 architecture and then trying to set up specific > service filters to contain the traffic seems like an L3 problem to me. >=20 > Claiming that L3 does not address "security threats" is not a reason = to > use TRILL since I would imagine setting "specific service filters" in > TRILL would have the same issues (and without the existing IETF L3 > security solutions we already have) >=20 > Don Dear Don, Typical home networks could use link-local addresses for all internal = devices without the filtering concern that effects enterprise level = deployments. In addition, the mDNS to DNS proxy scheme expects routable = addresses and rather ugly name conversion and base domain assignments = ignored in proposed specifications. In comparison, Rbridge which can be introduced incrementally, permits = continued use of link-local addressing and firewalls to avoid a = difficult task of assessing network boundaries. Devices using default = mDNS names would not suddenly become indirectly visible and various = network enabled displays that handle HDCP media still function within = the home. Even if Rbridge is not a viable solution, I would still request that we = look at the security impact of any proposal - even if it is just in the = form of a BCP that would be useful for deployment. Regards, Douglas Otis =20 --Apple-Mail=_70C649D2-D5C8-42C5-9441-B34BBBBBC982 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Apr 4, 2014, at 6:10 AM, Don Sturek = <d.sturek@att.net> = wrote:

Hi Douglas,

As one who follows the WG and = having a keen interest in homenet solutions,
I fail to see how TRILL = addresses the homenet problem set.

Producing a flat L2 = architecture and then trying to set up specific
service filters to = contain the traffic seems like an L3 problem to me.

Claiming that = L3 does not address "security threats" is not a reason to
use TRILL = since I would imagine setting "specific service filters" in
TRILL = would have the same issues (and without the existing IETF L3
security = solutions we already = have)

Don

Dear = Don,

Typical home networks could use link-local = addresses for all internal devices without the filtering concern that = effects enterprise level deployments.  In addition, the mDNS to DNS = proxy scheme expects routable addresses and rather ugly name conversion = and base domain assignments ignored in proposed = specifications.

In comparison, Rbridge which = can be introduced incrementally, permits continued use of link-local = addressing and firewalls to avoid a difficult task of assessing network = boundaries.  Devices using default mDNS names would not suddenly = become indirectly visible and various network enabled displays that = handle HDCP media still function within the = home.

Even if Rbridge is not a viable solution, I would still request = that we look at the security impact of any proposal - even if it is just = in the form of a BCP that would be useful for = deployment.

Regards,
Douglas = Otis

 


= --Apple-Mail=_70C649D2-D5C8-42C5-9441-B34BBBBBC982-- From nobody Fri Apr 4 09:45: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 28FA91A022F for ; Fri, 4 Apr 2014 09:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable 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 miQfZZvlXOhh for ; Fri, 4 Apr 2014 09:45:30 -0700 (PDT) Received: from nm3-vm3.access.bullet.mail.gq1.yahoo.com (nm3-vm3.access.bullet.mail.gq1.yahoo.com [216.39.63.61]) by ietfa.amsl.com (Postfix) with ESMTP id A91E51A01F3 for ; Fri, 4 Apr 2014 09:45:30 -0700 (PDT) Received: from [216.39.60.171] by nm3.access.bullet.mail.gq1.yahoo.com with NNFMP; 04 Apr 2014 16:45:26 -0000 Received: from [67.195.23.148] by tm7.access.bullet.mail.gq1.yahoo.com with NNFMP; 04 Apr 2014 16:45:26 -0000 Received: from [127.0.0.1] by smtp120.sbc.mail.gq1.yahoo.com with NNFMP; 04 Apr 2014 16:45:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1396629926; bh=EOKTfxj7xPlPZ2OXH/GkwDZL0W99e7TDi8SyF09/2DY=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:References:In-Reply-To:Mime-version:Content-type; b=AdDOxtB2IrnR9kWImxfRlJxHkKUumrXXIOx9qIPorAQ4yjoRfWMwII9DClyVXJ727P2yWV3hPMHnZgsPGqyoC3kaH4nSBK+VKQRVNfA5vrnYffh7MBBTfrpx1ELuLttxkQw596Zafge/gcXkLh5Q/q8bHnCb4TGXw2X+X+q34jo= X-Yahoo-Newman-Id: 9656.93824.bm@smtp120.sbc.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: DEutP.EVM1mh6DImZus0i6GDVzSA5wEEM2K.KiJm1gZmIWA OmPiJSnZa12sUdHqcDdqErkWQ5j8_h.NOetdO0t9Cdu42.1BligtsXNH3q4x 1VNZ3UUH4D4t6HvAcyPdIttjSDlFrbfT_VFnEoMH2JgTvHZ0mUFwn5XHAyuj djEuV4R8laUu8xvI8MIQH0n908.yCyjDjDpYxwiX3uoRGkNiFu7enyUF0FjX 6i5236wMpFmG1vOYa9uQ4873PoOnPRbcjsNb1EnhkrMcsAUJom6d.bPVzPYe Pwo6Xq0PRVE6dE_b.5yAAH07sIRDVuqC6bFmd8EUjYH7nfdZqbD02ImBHiUh J5UTVqoxkZYvfvItAKQOAYx6XfLG2.g.4S7TU0pYr9aXrCGE7x7OiT5x4TOU Lz8heouah38UvWa7nnGJFBY0TAnPlgSc42OzRDl1delUOqEKfB6NpNeFJO6L W4ULvCYdbNxZQ3xk5BacJ7o13L0u3jmM25BgEpm3NWv1nnalatCrmpkm1Xpk Ccy.jW_s7wUUBhL.B_4L7gt49I.9mOCQV X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-Rocket-Received: from [10.1.1.133] (d.sturek@66.27.60.174 with plain [67.195.15.5]) by smtp120.sbc.mail.gq1.yahoo.com with SMTP; 04 Apr 2014 16:45:25 +0000 UTC User-Agent: Microsoft-MacOutlook/14.3.9.131030 Date: Fri, 04 Apr 2014 09:45:17 -0700 From: Don Sturek To: Douglas Otis Message-ID: Thread-Topic: [homenet] [dnssd] IETF-89 WG meeting minutes References: <64E9ED15-A94D-4D80-9447-80C1E217E19A@gmail.com> <4DBFF820-72EE-4369-9837-AE15F81E5410@gmail.com> In-Reply-To: <4DBFF820-72EE-4369-9837-AE15F81E5410@gmail.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3479449524_111588" Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/Wf6iEZw4Y4rSQugbii9xPbwmz34 Cc: homenet@ietf.org, dnssd@ietf.org Subject: Re: [homenet] [dnssd] IETF-89 WG meeting minutes 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, 04 Apr 2014 16:45:35 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3479449524_111588 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi Douglas, I fail to see how turning all devices in a home into a flat link local-addressed architecture meets the requirments in the homenet charter (http://datatracker.ietf.org/wg/homenet/charter/), particularly around home/guest networks plus a few other areas of the charter. I also fail to see how turning all devices in a dnssd-type deployment into a flat link local-addressed architecture meets the requirements in the dnssd charter (http://datatracker.ietf.org/wg/dnssd/charter/) particularly around enterprise networks (eg campus networks) or mesh networks. Don From: Douglas Otis Date: Friday, April 4, 2014 8:08 AM To: Don Sturek Cc: , Subject: Re: [homenet] [dnssd] IETF-89 WG meeting minutes On Apr 4, 2014, at 6:10 AM, Don Sturek wrote: > Hi Douglas, > > As one who follows the WG and having a keen interest in homenet solutions, > I fail to see how TRILL addresses the homenet problem set. > > Producing a flat L2 architecture and then trying to set up specific > service filters to contain the traffic seems like an L3 problem to me. > > Claiming that L3 does not address "security threats" is not a reason to > use TRILL since I would imagine setting "specific service filters" in > TRILL would have the same issues (and without the existing IETF L3 > security solutions we already have) > > Don Dear Don, Typical home networks could use link-local addresses for all internal devices without the filtering concern that effects enterprise level deployments. In addition, the mDNS to DNS proxy scheme expects routable addresses and rather ugly name conversion and base domain assignments ignored in proposed specifications. In comparison, Rbridge which can be introduced incrementally, permits continued use of link-local addressing and firewalls to avoid a difficult task of assessing network boundaries. Devices using default mDNS names would not suddenly become indirectly visible and various network enabled displays that handle HDCP media still function within the home. Even if Rbridge is not a viable solution, I would still request that we look at the security impact of any proposal - even if it is just in the form of a BCP that would be useful for deployment. Regards, Douglas Otis _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet --B_3479449524_111588 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Hi Douglas,

=
I fail to see how turning all devices in a home into a flat link = local-addressed architecture meets the requirments in the homenet charter (<= a href=3D"http://datatracker.ietf.org/wg/homenet/charter">http://datatracker.i= etf.org/wg/homenet/charter/), particularly around home/guest networks pl= us a few other areas of the charter.

I also fail to= see how turning all devices in a dnssd-type deployment into a flat link loc= al-addressed architecture meets the requirements in the dnssd charter (http://datatracker.ietf.or= g/wg/dnssd/charter/) particularly around enterprise networks (eg campus = networks) or mesh networks.

Don



From: Dou= glas Otis <doug.mtview@gmail.com>
Date: Friday, April 4, 2014= 8:08 AM
To: Don Sturek <d.sturek@att.net>
Cc: <homenet@ietf.or= g>, <dnssd@ietf.org>
Subject: Re: [homenet] [dnssd] IETF-89 W= G meeting minutes


On Apr 4, 2014, at 6:10 AM, Don Sturek <d.sturek@att.net> wrote:

Hi Douglas,

As one who follows t= he WG and having a keen interest in homenet solutions,
I fail to see how = TRILL addresses the homenet problem set.

Producing a flat L2 architec= ture and then trying to set up specific
service filters to contain the tr= affic seems like an L3 problem to me.

Claiming that L3 does not addre= ss "security threats" is not a reason to
use TRILL since I would imagine = setting "specific service filters" in
TRILL would have the same issues (a= nd without the existing IETF L3
security solutions we already have)
Don

Dear Don,

<= div>Typical home networks could use link-local addresses for all internal de= vices without the filtering concern that effects enterprise level deployment= s.  In addition, the mDNS to DNS proxy scheme expects routable addresse= s and rather ugly name conversion and base domain assignments ignored in pro= posed specifications.

In comparison, Rbridge which = can be introduced incrementally, permits continued use of link-local address= ing and firewalls to avoid a difficult task of assessing network boundaries.=  Devices using default mDNS names would not suddenly become indirectly= visible and various network enabled displays that handle HDCP media still f= unction within the home.

Even if Rbridge is not a viable solution, I would still req= uest that we look at the security impact of any proposal - even if it is jus= t in the form of a BCP that would be useful for deployment.
=
Regards,
Douglas Otis

&nbs= p;


__________________________= _____________________ homenet mailing list homenet@ietf.org https://www.ietf.or= g/mailman/listinfo/homenet --B_3479449524_111588-- From nobody Fri Apr 4 09:55: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 364C81A0243; Fri, 4 Apr 2014 09:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 T-DkhplAvYti; Fri, 4 Apr 2014 09:54:54 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id D40B91A022A; Fri, 4 Apr 2014 09:54:54 -0700 (PDT) Received: from mb-aye.local ([173.247.205.34]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s34GsexM081652 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 4 Apr 2014 16:54:46 GMT (envelope-from joelja@bogus.com) Message-ID: <533EE3CA.1010108@bogus.com> Date: Fri, 04 Apr 2014 09:54:34 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:28.0) Gecko/20100101 Thunderbird/28.0 MIME-Version: 1.0 To: Don Sturek , Douglas Otis References: <64E9ED15-A94D-4D80-9447-80C1E217E19A@gmail.com> <4DBFF820-72EE-4369-9837-AE15F81E5410@gmail.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8xSQGpVIVWKe5NIcwXQnJc9WkAPISPqR9" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Fri, 04 Apr 2014 16:54:48 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/fLhqRB890q7qSj5Q7aMS85AjPyQ Cc: homenet@ietf.org, dnssd@ietf.org Subject: Re: [homenet] [dnssd] IETF-89 WG meeting minutes 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, 04 Apr 2014 16:54:59 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8xSQGpVIVWKe5NIcwXQnJc9WkAPISPqR9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 4/4/14, 9:45 AM, Don Sturek wrote: > Hi Douglas, >=20 > I fail to see how turning all devices in a home into a flat link > local-addressed architecture meets the requirments in the homenet chart= er > (http://datatracker.ietf.org/wg/homenet/charter/), particularly around > home/guest networks plus a few other areas of the charter. >=20 > I also fail to see how turning all devices in a dnssd-type deployment i= nto a > flat link local-addressed architecture meets the requirements in the dn= ssd > charter (http://datatracker.ietf.org/wg/dnssd/charter/) particularly ar= ound > enterprise networks (eg campus networks) or mesh networks. afaik dnssd wg/charter wouldn't need to exist if we were to constrain the problem space to a single L2 domain. So i think we can stipulate that the purpose is to work on a routed network. > Don >=20 >=20 >=20 > From: Douglas Otis > Date: Friday, April 4, 2014 8:08 AM > To: Don Sturek > Cc: , > Subject: Re: [homenet] [dnssd] IETF-89 WG meeting minutes >=20 >=20 > On Apr 4, 2014, at 6:10 AM, Don Sturek wrote: >=20 >> Hi Douglas, >> >> As one who follows the WG and having a keen interest in homenet soluti= ons, >> I fail to see how TRILL addresses the homenet problem set. >> >> Producing a flat L2 architecture and then trying to set up specific >> service filters to contain the traffic seems like an L3 problem to me.= >> >> Claiming that L3 does not address "security threats" is not a reason t= o >> use TRILL since I would imagine setting "specific service filters" in >> TRILL would have the same issues (and without the existing IETF L3 >> security solutions we already have) >> >> Don >=20 > Dear Don, >=20 > Typical home networks could use link-local addresses for all internal > devices without the filtering concern that effects enterprise level > deployments. In addition, the mDNS to DNS proxy scheme expects routabl= e > addresses and rather ugly name conversion and base domain assignments > ignored in proposed specifications. >=20 > In comparison, Rbridge which can be introduced incrementally, permits > continued use of link-local addressing and firewalls to avoid a difficu= lt > task of assessing network boundaries. Devices using default mDNS names= > would not suddenly become indirectly visible and various network enable= d > displays that handle HDCP media still function within the home. >=20 > Even if Rbridge is not a viable solution, I would still request that we= look > at the security impact of any proposal - even if it is just in the form= of a > BCP that would be useful for deployment. >=20 > Regards, > Douglas Otis >=20 > =20 >=20 >=20 > _______________________________________________ homenet mailing list > homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet >=20 >=20 >=20 >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet >=20 --8xSQGpVIVWKe5NIcwXQnJc9WkAPISPqR9 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/ iEYEARECAAYFAlM+48oACgkQ8AA1q7Z/VrKXbQCdHgaND2Uv1uflT18NdQbqiPsX ODwAmgNFaLxjFPP8rdhssUb4tXUNimeX =m9Py -----END PGP SIGNATURE----- --8xSQGpVIVWKe5NIcwXQnJc9WkAPISPqR9-- From nobody Fri Apr 4 11:17: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 4AA2F1A0265; Fri, 4 Apr 2014 11:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 bmVL2GXL6oGI; Fri, 4 Apr 2014 11:17:38 -0700 (PDT) Received: from mail-pb0-x22c.google.com (mail-pb0-x22c.google.com [IPv6:2607:f8b0:400e:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id F276B1A0231; Fri, 4 Apr 2014 11:17:37 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id rp16so3803338pbb.17 for ; Fri, 04 Apr 2014 11:17:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HMBQjeZSq9R2649yPL3KahxaQtb9JFoY7xzuOAJ3+nI=; b=uqHgtwVEckzOpgKbKXmECjIjNsdd/KVJOCwz3rxUsd+Tz+ZOWCWMnGefvuEVc0pKqA 3TVVEPEpC/EuvbCl8INcMDQ19/6zsHsuGLBiRw2HFUyCfVJjwGiMhQ9cpHZxdgRXYdjF zGbg0sK3YQzXll5GaVXAXjKMde35rARNSzHQgPZmrS3H1LSzeQwbMN/lmUYpF3ntQcWx yY6zTEyG65AYrS/63JziMRSXiNUYUWrT1JqcPeJp3GzavIJmkGytAMUf5tf41QQ3voX2 Swurk1ww+1rZ1+MKxpuWTAczBw33sDXov9pZ5HZvF6McVn/Y2sguKNWa9exPbq60Kd+z JRgg== X-Received: by 10.66.146.229 with SMTP id tf5mr16713996pab.50.1396635453498; Fri, 04 Apr 2014 11:17:33 -0700 (PDT) Received: from [10.156.49.10] (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPSA id yo9sm43936652pab.16.2014.04.04.11.17.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 04 Apr 2014 11:17:31 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Ralph Droms X-Mailer: iPad Mail (11D167) In-Reply-To: <533EE3CA.1010108@bogus.com> Date: Fri, 4 Apr 2014 11:17:31 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <49D1183A-DC66-400A-B61B-BB55468B9079@gmail.com> References: <64E9ED15-A94D-4D80-9447-80C1E217E19A@gmail.com> <4DBFF820-72EE-4369-9837-AE15F81E5410@gmail.com> <533EE3CA.1010108@bogus.com> To: "dnssd@ietf.org" Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/VM1MY4vfBTJ3VV2b4OU1prvXFM0 Cc: "homenet@ietf.org" Subject: Re: [homenet] [dnssd] IETF-89 WG meeting minutes 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, 04 Apr 2014 18:17:44 -0000 The charter of the dnssd WG is "to develop a solution for extended, scalable= DNS-SD." The charter mentions routed networks several times, implying that= any solution enveloped by the WG must be applicable to a routed network. The use of TRILL and RBridges for the WG DNS-SD solution has been discussed a= t length on the mailing list. Technically, this solution is not within the W= G charter, as it implies a single L2 domain with no routing. Pragmatically,= the solution is undeployable, as it would require a complete reorganization= of existing networks to solve the DNS-SD problem. Therefore, TRILL/RBridges is out of scope for the dnssd WG, and will not be f= urther discussed on the dnssd WG mailing list. - Ralph From nobody Fri Apr 4 11:41:26 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 794811A0235; Fri, 4 Apr 2014 11:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 ucGqWtTLTmqM; Fri, 4 Apr 2014 11:41:15 -0700 (PDT) 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 C6CC31A022B; Fri, 4 Apr 2014 11:41:15 -0700 (PDT) Received: by mail-pb0-f52.google.com with SMTP id rr13so3837841pbb.39 for ; Fri, 04 Apr 2014 11:41:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=g2aTUNqcS1MZp2onUNaxFBANcB3M/zO+cS3FjJErPzU=; b=eB+LhnIiytrGgPuRuvAwlMij81a2JwQanxlTAtqXDWLbRwlveJ6w7H5KZmSr9qLB9f 70HYe+s8IFXXDR94L7p55e3kVgPFpqjGDHb8SSiIyvpHhjSlV6UJc8MEjCExvmcyi7vM p/qJFYbyNQgshC2BbzMAZgqoKfjhgSmiKH+zy3vxUthAJZYy5KwZ/ryLKm6VNtG9bCVi /jLzjgaJDJ/IUz020J0NymP5mCnnqsi+qWF1YYAy6d8fKQBZFqkk6HcEYFjO+BfXAT62 EoRy78qTz7UNr322xyKS+ctwfdsz9wXVJgiIDOZQRvUrkxBnGTz6Ce9I8tG/lKVtn50g RtoQ== X-Received: by 10.66.254.198 with SMTP id ak6mr11526812pad.156.1396636871191; Fri, 04 Apr 2014 11:41:11 -0700 (PDT) Received: from [192.168.2.245] (c-67-188-1-12.hsd1.ca.comcast.net. [67.188.1.12]) by mx.google.com with ESMTPSA id nx12sm44202294pab.6.2014.04.04.11.41.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 04 Apr 2014 11:41:10 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Content-Type: text/plain; charset=iso-8859-1 From: Douglas Otis In-Reply-To: <533EE3CA.1010108@bogus.com> Date: Fri, 4 Apr 2014 11:41:09 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <64E9ED15-A94D-4D80-9447-80C1E217E19A@gmail.com> <4DBFF820-72EE-4369-9837-AE15F81E5410@gmail.com> <533EE3CA.1010108@bogus.com> To: joel jaeggli X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/2cE2C4f4Bhpu7oXdtlPO31DqUCU Cc: homenet@ietf.org, Don Sturek , dnssd@ietf.org Subject: Re: [homenet] [dnssd] IETF-89 WG meeting minutes 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, 04 Apr 2014 18:41:20 -0000 On Apr 4, 2014, at 9:54 AM, joel jaeggli wrote: > On 4/4/14, 9:45 AM, Don Sturek wrote: >> Hi Douglas, >>=20 >> I fail to see how turning all devices in a home into a flat link >> local-addressed architecture meets the requirments in the homenet = charter >> (http://datatracker.ietf.org/wg/homenet/charter/), particularly = around >> home/guest networks plus a few other areas of the charter. >>=20 >> I also fail to see how turning all devices in a dnssd-type deployment = into a >> flat link local-addressed architecture meets the requirements in the = dnssd >> charter (http://datatracker.ietf.org/wg/dnssd/charter/) particularly = around >> enterprise networks (eg campus networks) or mesh networks. >=20 > afaik dnssd wg/charter wouldn't need to exist if we were to constrain > the problem space to a single L2 domain. So i think we can stipulate > that the purpose is to work on a routed network. Dear Joel, Thank you for you feedback. I am sure they represent what could be = described as naive wishful desires. Careful review of the Educause = petition indicates their specific desires are NOT satisfied with layer 3 = solutions due to additional constraints not within the vendor's purview = of which they seem unaware. The constraint limiting the scope of mDNS is due to typical bridge = operation. This constraint is better resolved using an _incremental_ = layer 2 solution offering TLV table based MAC exchanges to permit = routing at this level rather than use of layer 3 IP routing which has = the effect of disabling desired services.=20 Within our organization at a similar scale, this issue has been resolved = using enterprise grade switches and non-trival configuration. Use of = Rbridge, as an example, eliminates complexity without weakening security = where network boundaries become indeterminate. At the home scale, no = service filters should be needed. At the Educause scale, filters for desired services will be needed. In = good conscience, this additional requirement should be part of a DNSSD = work product! Apple currently offers global DNS to locate devices based = on Kerberos individual account authentications before publishing. There = is no reason a similar strategy can't be used within the home network by = bundling requisite services to explicitly authenticate devices made = visible via DNS. This would also likely satisfy needs of networks = unable to support mDNS. Placement of translated mDNS resources MUST NOT be published into DNS = due to many security considerations never reasonably satisfied. mDNS = should not be considered a safe method to publish internal resources = when it impairs network boundary detection and potentially lists devices = having default names indirectly accessible by remote actors. Please consider security implications for deployers as part of this = thought process. Even if only published as a BCP, it would be most = helpful. Regards, Douglas Otis =20 =20 =20 From nobody Fri Apr 4 11:50: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 65F231A049A; Fri, 4 Apr 2014 11:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.511 X-Spam-Level: X-Spam-Status: No, score=-9.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 0k14sO-L46-u; Fri, 4 Apr 2014 11:50:04 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id 2A59F1A048E; Fri, 4 Apr 2014 11:50:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10567; q=dns/txt; s=iport; t=1396637398; x=1397846998; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=dgHfJI5Jp1MxULyUkaUAoMqIH5ieyhG61sd4qGn65/E=; b=ML4WQ0kM4PKdPTQso1bbbRgmOAfrCR7Wpb5doLqMsaExXInao1MOe1b+ oR60dyVynGV16G4XApLpTcarSKX/GaoJSM3Ah/SycgCuwSV7sVnhVZuWp ZaOapV3iiASHSpNUswh4sJL2uW+EVo3JMxqNi/vcDAGTofcPVlAauvsu4 0=; X-Files: smime.p7s : 4945 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMFAEX9PlOtJV2Z/2dsb2JhbABZgwY7V7xXhzeBJBZ0giUBAQEEAQEBawsQAgEIDgQGFRkCHwYLFw4CBAENBQ4Nh0oDEQ3IfQ2HAxeMV4IaBwqELgSQX4E1hFqBbYE0izyFT4Mwgis X-IronPort-AV: E=Sophos;i="4.97,796,1389744000"; d="p7s'?scan'208";a="33126031" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-2.cisco.com with ESMTP; 04 Apr 2014 18:49:58 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s34InwYH025134 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 4 Apr 2014 18:49:58 GMT Received: from xmb-rcd-x11.cisco.com ([169.254.1.75]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Fri, 4 Apr 2014 13:49:57 -0500 From: "Stephen Orr (sorr)" To: Douglas Otis , joel jaeggli Thread-Topic: [dnssd] [homenet] IETF-89 WG meeting minutes Thread-Index: AQHPUDV7EKoSxBcPlkyL48/WECXJMpsB3bUA Date: Fri, 4 Apr 2014 18:49:57 +0000 Message-ID: References: <64E9ED15-A94D-4D80-9447-80C1E217E19A@gmail.com> <4DBFF820-72EE-4369-9837-AE15F81E5410@gmail.com> <533EE3CA.1010108@bogus.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.116.148.216] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3479467800_2895945" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/59ip8FIM1KWRVY1Hkmwk-QGQUUQ Cc: "homenet@ietf.org" , Don Sturek , "dnssd@ietf.org" Subject: Re: [homenet] [dnssd] IETF-89 WG meeting minutes 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, 04 Apr 2014 18:50:08 -0000 --B_3479467800_2895945 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi Doug, We currently have a draft published: https://datatracker.ietf.org/doc/draft-bhandari-dnssd-mdns-gateway/ That addresses the service filtering component that you reference. On 4/4/14, 2:41 PM, "Douglas Otis" wrote: > >On Apr 4, 2014, at 9:54 AM, joel jaeggli wrote: > >> On 4/4/14, 9:45 AM, Don Sturek wrote: >>> Hi Douglas, >>> >>> I fail to see how turning all devices in a home into a flat link >>> local-addressed architecture meets the requirments in the homenet >>>charter >>> (http://datatracker.ietf.org/wg/homenet/charter/), particularly around >>> home/guest networks plus a few other areas of the charter. >>> >>> I also fail to see how turning all devices in a dnssd-type deployment >>>into a >>> flat link local-addressed architecture meets the requirements in the >>>dnssd >>> charter (http://datatracker.ietf.org/wg/dnssd/charter/) particularly >>>around >>> enterprise networks (eg campus networks) or mesh networks. >> >> afaik dnssd wg/charter wouldn't need to exist if we were to constrain >> the problem space to a single L2 domain. So i think we can stipulate >> that the purpose is to work on a routed network. > >Dear Joel, > >Thank you for you feedback. I am sure they represent what could be >described as naive wishful desires. Careful review of the Educause >petition indicates their specific desires are NOT satisfied with layer 3 >solutions due to additional constraints not within the vendor's purview >of which they seem unaware. > >The constraint limiting the scope of mDNS is due to typical bridge >operation. This constraint is better resolved using an _incremental_ >layer 2 solution offering TLV table based MAC exchanges to permit routing >at this level rather than use of layer 3 IP routing which has the effect >of disabling desired services. > >Within our organization at a similar scale, this issue has been resolved >using enterprise grade switches and non-trival configuration. Use of >Rbridge, as an example, eliminates complexity without weakening security >where network boundaries become indeterminate. At the home scale, no >service filters should be needed. > >At the Educause scale, filters for desired services will be needed. In >good conscience, this additional requirement should be part of a DNSSD >work product! Apple currently offers global DNS to locate devices based >on Kerberos individual account authentications before publishing. There >is no reason a similar strategy can't be used within the home network by >bundling requisite services to explicitly authenticate devices made >visible via DNS. This would also likely satisfy needs of networks unable >to support mDNS. > >Placement of translated mDNS resources MUST NOT be published into DNS due >to many security considerations never reasonably satisfied. mDNS should >not be considered a safe method to publish internal resources when it >impairs network boundary detection and potentially lists devices having >default names indirectly accessible by remote actors. > >Please consider security implications for deployers as part of this >thought process. Even if only published as a BCP, it would be most >helpful. > >Regards, >Douglas Otis > > > > > > > > >_______________________________________________ >dnssd mailing list >dnssd@ietf.org >https://www.ietf.org/mailman/listinfo/dnssd --B_3479467800_2895945 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIITTQYJKoZIhvcNAQcCoIITPjCCEzoCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghECMIIG8TCCBdmgAwIBAgIQD6y3tvjsPqGizAAWDNs+vzANBgkqhkiG9w0BAQsFADBl MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTMx MTI3MDAwMDAwWhcNMTQxMTI3MTIwMDAwWjCBlDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNh bGlmb3JuaWExETAPBgNVBAcTCFNhbiBKb3NlMRwwGgYDVQQKExNDaXNjbyBTeXN0ZW1zLCBJ bmMuMQowCAYDVQQLEwExMRQwEgYDVQQDEwtTdGVwaGVuIE9ycjEdMBsGCSqGSIb3DQEJARMO c29yckBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Q1rb5zUt KHXEQFPnS7D2H/zN3/NMEfVoXqFwYSrAYlSsxS+G50RDbKbNOleGeSgkDk2tSHsRe4X7XcUJ Ea0Y0u2Q2H5Y99ba+lRMF8meDLN59lNxabElsG1KktmS7Doi5IzUBxku65MdzEfA8JIPXD9g MXpCqtWlOhntmhZfwONo8H0EpQqm+muoK4SUfWZgjrBl1GjitBKJ3iO9so4OT34bYXxUKo9b LU34x31MoGPfWMEbfAOP3kfs0eP/R+5GZWThA8X0Fb3wvU8WVWWNjPnn0TO/CgUROiWRn8mJ rrIfZ7FpHCP6FO4LI1onaIc71LqMd55QI/ttZit/7FB/AgMBAAGjggNrMIIDZzAfBgNVHSME GDAWgBTnAiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQU2HUQM2kELC5/oRDsjgwuZsHq xikwGQYDVR0RBBIwEIEOc29yckBjaXNjby5jb20wDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQW MBQGCCsGAQUFBwMEBggrBgEFBQcDAjCBiAYDVR0fBIGAMH4wPaA7oDmGN2h0dHA6Ly9jcmwz LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVkSURDQS1nMS5jcmwwPaA7oDmGN2h0 dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVkSURDQS1nMS5jcmww ggHFBgNVHSAEggG8MIIBuDCCAbQGCmCGSAGG/WwEAQIwggGkMDoGCCsGAQUFBwIBFi5odHRw Oi8vd3d3LmRpZ2ljZXJ0LmNvbS9zc2wtY3BzLXJlcG9zaXRvcnkuaHRtMIIBZAYIKwYBBQUH AgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAAbwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBm AGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBj AGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIAdAAgAEMAUAAvAEMAUABTACAAYQBu AGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0AHkAIABBAGcAcgBlAGUAbQBl AG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5ACAAYQBu AGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4AIABi AHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYY aHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEMGCCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5k aWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJlZElEQ0EuY3J0MAwGA1UdEwEB/wQCMAAw DQYJKoZIhvcNAQELBQADggEBALaIx4pCwM+XAFf8BQx378wzyRGRH5WfkNmDS3PJVuN7Dhv5 1ZxUHMwSz7Ev8pp38ItOsoVnfYepHFGemxIzU5X0PuuFSvWE8ajXP4XfU+IeqSWxvC2vHj8p Vvaj8Wdz5EGJif7R0OvDHZqjNhB/uRzEDLiWW3bvQBGPHEwrxWMlJ4ZgIs4QTkM5+HCIG/g8 XB0N1YY5m3XkNHe38U+YqUpkqBuvIUShJfiznN5mYlPEfb/wzdYizkWYFlyzAdDpwtCbqm3P hueYfpLewopK54WU1Q8Qm98t6f8Ub1QAtIHd0KNAFPlaXjDTo/m8TUr9SsxHRQs8ox5VQEzF xNjBVtMwggZOMIIFNqADAgECAhAErnlgZmaQGrnFf6ZsW9zNMA0GCSqGSIb3DQEBCwUAMGUx CzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdp Y2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0xMzEx MDUxMjAwMDBaFw0yODExMDUxMjAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdp Q2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0 IFNIQTIgQXNzdXJlZCBJRCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANz4 ESM/arXvwCd5Gy0Fh6IQQzHfDtQVG093pCLOPoxw8L4Hjt0nKrwBHbYsCsrdaVgfQe1qBR/a Y3hZHiIsK/i6fsk1O1bxH3xCfiWwIxnGRTjXPUT5IHxgrhywWhgEvo8796nwlJqmDGNJtkEX U0AyvU/mUHpQHyVF6PGJr83/Xv9Q8/AXEf+9xYn1vWK52PuORQSFbZnNxUhN/SarAjZF6jbX X2riGoJBCtzp2fWRF47GIa04PBPmHn9mnNVN2Uba9s9Sp307JMO0wVE1xpvr1O9+5HsD4US9 egs34E/LgooNcRjkpuCJLBvzsnM8wbCSnhh9vat9xX0IoSzCn3MCAwEAAaOCAvgwggL0MBIG A1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMDQGCCsGAQUFBwEBBCgwJjAkBggr BgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMIGBBgNVHR8EejB4MDqgOKA2hjRo dHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290Q0EuY3JsMDqg OKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290Q0Eu Y3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDCCAbMGA1UdIASCAaowggGmMIIB ogYKYIZIAYb9bAACBDCCAZIwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNv bS9DUFMwggFkBggrBgEFBQcCAjCCAVYeggFSAEEAbgB5ACAAdQBzAGUAIABvAGYAIAB0AGgA aQBzACAAQwBlAHIAdABpAGYAaQBjAGEAdABlACAAYwBvAG4AcwB0AGkAdAB1AHQAZQBzACAA YQBjAGMAZQBwAHQAYQBuAGMAZQAgAG8AZgAgAHQAaABlACAARABpAGcAaQBDAGUAcgB0ACAA QwBQAC8AQwBQAFMAIABhAG4AZAAgAHQAaABlACAAUgBlAGwAeQBpAG4AZwAgAFAAYQByAHQA eQAgAEEAZwByAGUAZQBtAGUAbgB0ACAAdwBoAGkAYwBoACAAbABpAG0AaQB0ACAAbABpAGEA YgBpAGwAaQB0AHkAIABhAG4AZAAgAGEAcgBlACAAaQBuAGMAbwByAHAAbwByAGEAdABlAGQA IABoAGUAcgBlAGkAbgAgAGIAeQAgAHIAZQBmAGUAcgBlAG4AYwBlAC4wHQYDVR0OBBYEFOcC I4AAT9jXvJQL2T90OUkyPIp5MB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0G CSqGSIb3DQEBCwUAA4IBAQBO1Iknuf0dh3d+DygFkPEKL8k7Pr2TnJDGr/qRUYcyVGvoysFx UVyZjrX64GIZmaYHmnwTJ9vlAqKEEtkV9gpEV8Q0j21zHzrWoAE93uOC5EVrsusl/YBeHTmQ vltC9s6RYOP5oFYMSBDOM2h7zZOr8GrLT1gPuXtdGwSBnqci4ldJJ+6Skwi+aQhTAjouXcgZ 9FCATgLZsF2RtJOH+ZaWgVVAjmbtgti7KF/tTGHtBlgoGVMRRLxHICmyBGzYiVSZO3XbZ3gs HpJ4xlU9WBIRMm69QwxNNNt7xkLb7L6rm2FMBpLjjt8hKlBXBMBgojXVJJ5mNwlJz9X4ZbPg 4m7CMIIDtzCCAp+gAwIBAgIQDOfg5RfYRv6P5WD8G/AwOTANBgkqhkiG9w0BAQUFADBlMQsw CQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNl cnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJvb3QgQ0EwHhcNMDYxMTEw MDAwMDAwWhcNMzExMTEwMDAwMDAwWjBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNl cnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBB c3N1cmVkIElEIFJvb3QgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtDhXO 5EOAXLGH87dg+XESpa7cJpSIqvTO9SA5KFhgDPiA2qkVlTJhPLWxKISKityfCgyDF3qPkKyK 53lTXDGEKvYPmDI2dsze3Tyoou9q+yHyUmHfnyDXH+Kx2f4YZNISW1/5WBg1vEfNoTb5a3/U sDg+wRvDjDPZ2C8Y/igPs6eD1sNuRMBhNZYW/lmci3Zt1/GiSw0r/wty2p5g0I6QNcZ4VYcg oc/lbQrISXwxmDNsIumH0DJaoroTghHtORedmTpyoeb6pNnVFzF1roV9Iq4/AUaG9ih5yLHa 5FcXxH4cDrC0kqZWs72yl+2qp/C3xag/lRbQ/6GW6whfGHdPAgMBAAGjYzBhMA4GA1UdDwEB /wQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBRF66Kv9JLLgjEtUYunpyGd823I DzAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQUFAAOCAQEA og683+Lt8ONyc3pklL/3cmbYMuRCdWKuh+vy1dneVrOfzM4UKLkNl2BcEkxY5NM9g0lFWJc1 aRqoR+pWxnmrEthngYTffwk8lOa4JiwgvT2zKIn3X/8i4peEH+ll74fg38FnSbNd67IJKusm 7Xi+fT8r87cmNW1fiQG2SVufAQWbqz0lwcy2f8Lxb4bG+mRo64EtlOtCt/qMHt1i8b5QZ7ds vfPxH2sMNgcWfzd8qVttevESRmCD1ycEvkvOl77DZypoEd+A5wwzZr8TDRRu838fYxAe+o0b JW1sj6W3YQGx0qMmoRBxna3iw/nDmVG3KwcIzi7mULKn+gpFL6Lw8jGCAg8wggILAgEBMHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRp Z2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAPrLe2 +Ow+oaLMABYM2z6/MA0GCWCGSAFlAwQCAQUAoGkwLwYJKoZIhvcNAQkEMSIEICvH0hp5WWZ6 tv9uJcF1g1hcr8PYtC4be1MreHHjcD34MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTE0MDQwNDE4NTAwMFowDQYJKoZIhvcNAQEBBQAEggEAAdgwOX/An2t0 iZNXZYtG5roopgFhmdu24TZ6ni/6WlCCMl1PFR7NOul2M0QkyneGdK+WmQKlL54GmNePl7wq rn9Ma4+WF0hfzSvlst0HTFzQlr58H0QVijwdqBk91IBu+Z7o066ehczDW4lEswySkEEVyfca AlQ0HNJ5rL317qUSeO6TFG6g3qkRtkTMp0wMNWCXeOYVfQnIQPv65ObsovUW1YZISh8vxySE ef3k18nh5pdtg0XQPnApyOTfMth1PGIf3ejEyUJb8BWzpACflyshzVybSuX7oV1HmnRYtN5E PWNuf56MqbJOn/mHYlk0CI/0LWP67tyOA81F4V7k2g== --B_3479467800_2895945-- From nobody Sun Apr 6 10:36: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 C1D601A01BA; Sun, 6 Apr 2014 10:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.027 X-Spam-Level: X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 hripeKdiHqNP; Sun, 6 Apr 2014 10:35:58 -0700 (PDT) Received: from mail-oa0-x230.google.com (mail-oa0-x230.google.com [IPv6:2607:f8b0:4003:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id B18AA1A0161; Sun, 6 Apr 2014 10:35:58 -0700 (PDT) Received: by mail-oa0-f48.google.com with SMTP id m1so5682522oag.35 for ; Sun, 06 Apr 2014 10:35:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=oLvtX60pchOCeV8RoQn/AVEK3DE7etXqxvsXy5QZ4RI=; b=tX5Zxu+Nh0W3HpXrZiS5ceARcV+6odWKoyjwG49NmhK+otzm03ae3K07ta/jJrpRo/ 8+OFkkLibRLZlaYnW4dTY2e4KlvSY1jw6pxordYFYrNr9Fvge1q7BuOh9h7sl+JOOa/H fGsBU7VcYDn+Z6s4aefT0XZYKBiC7mibpWgF1NnHrYKYMSo3cCQyzLWodUreQcL2coR4 IsjeqhtA7FYM9EKII91dK4+2C1IGKvNCSBt/P9EWZ+2+hAAQB7B7r9oyEucPBKtfzE4O y6eghqGw1zCIX4aaG9pBoSa3ZYZgKH5N1aTuyAiUFahNePXdiisLitZzokT1wOnPyDk1 gKAQ== MIME-Version: 1.0 X-Received: by 10.60.44.42 with SMTP id b10mr102797oem.70.1396805753256; Sun, 06 Apr 2014 10:35:53 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.60.76.137 with HTTP; Sun, 6 Apr 2014 10:35:53 -0700 (PDT) In-Reply-To: <57FAC168-F82D-4C7A-8E30-E217BC1E98EB@bangj.com> References: <64E9ED15-A94D-4D80-9447-80C1E217E19A@gmail.com> <4DBFF820-72EE-4369-9837-AE15F81E5410@gmail.com> <57FAC168-F82D-4C7A-8E30-E217BC1E98EB@bangj.com> Date: Sun, 6 Apr 2014 13:35:53 -0400 X-Google-Sender-Auth: L_fSlfPnPyp2QWbzAmUF8Z7OlTg Message-ID: From: Kerry Lynn To: Tom Pusateri Content-Type: multipart/alternative; boundary=001a11c30a04be3e6404f6632e2f Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/pwTDB9FsuQrcm07aFoRRizuqVFI Cc: dnssd@ietf.org, "homenet@ietf.org Group" , Don Sturek , Douglas Otis Subject: Re: [homenet] [dnssd] IETF-89 WG meeting minutes 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, 06 Apr 2014 17:36:03 -0000 --001a11c30a04be3e6404f6632e2f Content-Type: text/plain; charset=ISO-8859-1 On Fri, Apr 4, 2014 at 11:25 AM, Tom Pusateri wrote: > > Dear Don, > > Even if Rbridge is not a viable solution, I would still request that we > look at the security impact of any proposal - even if it is just in the > form of a BCP that would be useful for deployment. > > Regards, > Douglas Otis > > > Douglas, > > The security impact of any proposal will be evaluated against the security > section of the requirements draft found here: > > http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirements/ > > If you feel as though there are additional security requirements to > evaluate the solution space against that are not found in the requirements > document, please contribute text to this section. > > The documents generated by this WG (such as BCPs) are in response to the > milestones in the WG charter found here: > > http://datatracker.ietf.org/wg/dnssd/charter/ > > If you feel that additional documents need to be written and those > documents are not covered in the current milestones, then you can propose > changes to the charter for approval by the WG. > > Thanks, > Tom > > > > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd > > Douglas, As I hope to get a WGLC-worthy draft of the Requirements doc out for review in the next few days, I would appreciate any text you can contribute to security requirements. Regards, -K- --001a11c30a04be3e6404f6632e2f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Apr 4, 2014 at 11:25 AM, Tom Pusateri <pusateri@= bangj.com> wrote:

Dear Do= n,

Even if Rbridge is not a viable solution, I would still request that we l= ook at the security impact of any proposal - even if it is just in the form= of a BCP that would be useful for deployment.

Regards,
Douglas Otis
=

Douglas,

The security = impact of any proposal will be evaluated against the security section of th= e requirements draft found here:


If you feel as thoug= h there are additional security requirements to evaluate the solution space= against that are not found in the requirements document, please contribute= text to this section.

The documents generated by this WG (such as BCPs) are i= n response to the milestones in the WG charter found here:


If you feel that additional documents need to be writte= n and those documents are not covered in the current milestones, then you c= an propose changes to the charter for approval by the WG.

Thanks,
Tom



________= _______________________________________
dnssd mailing list
dnssd@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dnssd

Douglas,

As = I hope to get a WGLC-worthy draft of the Requirements doc out for review in= the next
few days, I would appreciate = any text you can contribute to security requirements.

Regards, -K-
--001a11c30a04be3e6404f6632e2f-- From nobody Sun Apr 6 21:13:37 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 74F5A1A02AC; Sun, 6 Apr 2014 21:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 F5PchKuenp9Z; Sun, 6 Apr 2014 21:13:28 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id D47A91A01B0; Sun, 6 Apr 2014 21:13:28 -0700 (PDT) Received: from mb-aye.local (c-50-174-19-240.hsd1.ca.comcast.net [50.174.19.240]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s374DGtc013260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 7 Apr 2014 04:13:19 GMT (envelope-from joelja@bogus.com) Message-ID: <534225D6.7070009@bogus.com> Date: Sun, 06 Apr 2014 21:13:10 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:28.0) Gecko/20100101 Thunderbird/28.0 MIME-Version: 1.0 To: Douglas Otis References: <64E9ED15-A94D-4D80-9447-80C1E217E19A@gmail.com> <4DBFF820-72EE-4369-9837-AE15F81E5410@gmail.com> <533EE3CA.1010108@bogus.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="iCoqDw0QPE6lW4GpAcAtiXrv0X4pcsFB1" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Mon, 07 Apr 2014 04:13:21 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/5gfdgkuC6lwWQW_lhe-I67m7S0E Cc: homenet@ietf.org, Don Sturek , dnssd@ietf.org Subject: Re: [homenet] [dnssd] IETF-89 WG meeting minutes 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, 07 Apr 2014 04:13:33 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --iCoqDw0QPE6lW4GpAcAtiXrv0X4pcsFB1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 4/4/14, 11:41 AM, Douglas Otis wrote: >=20 > On Apr 4, 2014, at 9:54 AM, joel jaeggli wrote: >=20 >> On 4/4/14, 9:45 AM, Don Sturek wrote: >>> Hi Douglas, >>>=20 >>> I fail to see how turning all devices in a home into a flat link=20 >>> local-addressed architecture meets the requirments in the homenet >>> charter (http://datatracker.ietf.org/wg/homenet/charter/), >>> particularly around home/guest networks plus a few other areas of >>> the charter. >>>=20 >>> I also fail to see how turning all devices in a dnssd-type >>> deployment into a flat link local-addressed architecture meets >>> the requirements in the dnssd charter >>> (http://datatracker.ietf.org/wg/dnssd/charter/) particularly >>> around enterprise networks (eg campus networks) or mesh >>> networks. >>=20 >> afaik dnssd wg/charter wouldn't need to exist if we were to >> constrain the problem space to a single L2 domain. So i think we >> can stipulate that the purpose is to work on a routed network. >=20 > Dear Joel, >=20 > Thank you for you feedback. I am sure they represent what could be > described as naive wishful desires. Careful review of the Educause > petition indicates their specific desires are NOT satisfied with > layer 3 solutions due to additional constraints not within the > vendor's purview of which they seem unaware. Afaik we're operating under a wg charter not the educause petition and I see no reason the discussion should be lititgated on basis of the later. > The constraint limiting the scope of mDNS is due to typical bridge > operation. This constraint is better resolved using an _incremental_ > layer 2 solution offering TLV table based MAC exchanges to permit > routing at this level rather than use of layer 3 IP routing which has > the effect of disabling desired services. That would seem to arbirarily constrain the diameter to an l2 domain. Sure you can build your topology that way, many if not most organizations do not. They have good reasons for doing so. > Within our organization at a similar scale, this issue has been > resolved using enterprise grade switches and non-trival > configuration. Use of Rbridge, as an example, eliminates complexity > without weakening security where network boundaries become > indeterminate. At the home scale, no service filters should be > needed. >=20 > At the Educause scale, filters for desired services will be needed. > In good conscience, this additional requirement should be part of a > DNSSD work product! Apple currently offers global DNS to locate > devices based on Kerberos individual account authentications before > publishing. There is no reason a similar strategy can't be used > within the home network by bundling requisite services to explicitly > authenticate devices made visible via DNS. This would also likely > satisfy needs of networks unable to support mDNS. >=20 > Placement of translated mDNS resources MUST NOT be published into DNS > due to many security considerations never reasonably satisfied. mDNS > should not be considered a safe method to publish internal resources > when it impairs network boundary detection and potentially lists > devices having default names indirectly accessible by remote actors. >=20 > Please consider security implications for deployers as part of this > thought process. Even if only published as a BCP, it would be most > helpful. >=20 > Regards, Douglas Otis >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 --iCoqDw0QPE6lW4GpAcAtiXrv0X4pcsFB1 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/ iEYEARECAAYFAlNCJdcACgkQ8AA1q7Z/VrJuEACffjZwPFOqLmTlakKy5eRaiegp etsAn2sqURgD01nAXApg39HybbBtO3J6 =y//O -----END PGP SIGNATURE----- --iCoqDw0QPE6lW4GpAcAtiXrv0X4pcsFB1-- From nobody Sun Apr 6 21:32:36 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 3DE001A064B; Sun, 6 Apr 2014 21:32:32 -0700 (PDT) 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 5lCCJagA4Fg0; Sun, 6 Apr 2014 21:32:28 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 634BE1A0676; Sun, 6 Apr 2014 21:32:24 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id z2so4347313wiv.12 for ; Sun, 06 Apr 2014 21:32:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=1LKDx9mD/YxpJN7HRybs23mTPO5BAmv8wPUEnzYUrtU=; b=uyjeHnnD2HHLsTnVfErT8kW9XCw9BXN7L0abCkPYFAfySVOozZwd4XHKOjzrkK0Enn i2po54YhkXPvuxJqXW6EXynFD2aq1GxWOchZ1PTHRTnQTVYzQOeietQeJmaYeLzx9d5q DTfZgxSRGJli3sOnGE+H13DN6wSoBavr9WsUfpX3iVGKhahGAebqw9V9GP6btlOJyNbe kR8fogvHMr72XcoQX/c02jpvC1OFpmO05zWasM0ZKwi2NPx7q4wnQDxP1lvW7NBQiGlH rO6fOkpjTHsrjAq3Fm0IhnAjDlIS4LxqOL01UMV3W4xpL6aZAl1AG9pVVJH5koiiQE5L Bgwg== MIME-Version: 1.0 X-Received: by 10.180.188.169 with SMTP id gb9mr22784689wic.17.1396845138266; Sun, 06 Apr 2014 21:32:18 -0700 (PDT) Received: by 10.216.177.10 with HTTP; Sun, 6 Apr 2014 21:32:18 -0700 (PDT) In-Reply-To: <4DBFF820-72EE-4369-9837-AE15F81E5410@gmail.com> References: <64E9ED15-A94D-4D80-9447-80C1E217E19A@gmail.com> <4DBFF820-72EE-4369-9837-AE15F81E5410@gmail.com> Date: Sun, 6 Apr 2014 21:32:18 -0700 Message-ID: From: Dave Taht To: Douglas Otis Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/5LRsF8PnRClHc4M_LcyuLhaTqug Cc: HOMENET , Don Sturek , dnssd@ietf.org Subject: Re: [homenet] [dnssd] IETF-89 WG meeting minutes 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, 07 Apr 2014 04:32:32 -0000 On Fri, Apr 4, 2014 at 8:08 AM, Douglas Otis wrote: > > On Apr 4, 2014, at 6:10 AM, Don Sturek wrote: > > Hi Douglas, > > As one who follows the WG and having a keen interest in homenet solutions= , > I fail to see how TRILL addresses the homenet problem set. > > Producing a flat L2 architecture and then trying to set up specific > service filters to contain the traffic seems like an L3 problem to me. > > Claiming that L3 does not address "security threats" is not a reason to > use TRILL since I would imagine setting "specific service filters" in > TRILL would have the same issues (and without the existing IETF L3 > security solutions we already have) > > Don > > > Dear Don, > > Typical home networks could use link-local addresses for all internal > devices without the filtering concern that effects enterprise level > deployments. The day that spanning tree or trill works well over wireless 802.11, 802.14, lte, etc will be the day that I start thinking it's suitable for home use. If the DCB folk were to try implementing their stuff on 802.11 in particular, with it's 1mbit/sec multicast rate, perhaps we would come to a meeting of the minds. > In addition, the mDNS to DNS proxy scheme expects routable > addresses and rather ugly name conversion and base domain assignments > ignored in proposed specifications. They are, at least, consistent. > In comparison, Rbridge which can be introduced incrementally, permits > continued use of link-local addressing and firewalls to avoid a difficult > task of assessing network boundaries. Devices using default mDNS names > would not suddenly become indirectly visible and various network enabled > displays that handle HDCP media still function within the home. Service discovery and service access are different things. I don't mind (that much) if some larger subset of people than I really want can see that a resource such as "TRACI LORDS PR0N COLLECTION" exists on the network, so long only the right people can actually access it. [1] But others may. The scope of announcing that something exists may well need to be restricte= d somehow. > > Even if Rbridge is not a viable solution, I would still request that we l= ook > at the security impact of any proposal - even if it is just in the form o= f a > BCP that would be useful for deployment. I agree that security needs to be looked at harder in homenet and dnssd. I fail to see how rbridge solves anything from a security perspective if you have home/guest lans, or any other natural division of link layer technologies. Please implement rbridge support over a busy wireless lan and get back to us. > > Regards, > Douglas Otis > [1] Yes, I've seen a resource announced like this. When mounted, it contained an admonishment to not do illegal things, and a bunch of pointers to things like: http://en.wikipedia.org/wiki/Great_Tit > > > > _______________________________________________ > 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 Thu Apr 10 16:53:11 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 5AB911A035B; Thu, 10 Apr 2014 16:53:10 -0700 (PDT) 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_50=0.8, 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 mjxP2ZSDmw5h; Thu, 10 Apr 2014 16:53:09 -0700 (PDT) Received: from mail-pb0-x22f.google.com (mail-pb0-x22f.google.com [IPv6:2607:f8b0:400e:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA3B1A0357; Thu, 10 Apr 2014 16:53:09 -0700 (PDT) Received: by mail-pb0-f47.google.com with SMTP id up15so4621777pbc.34 for ; Thu, 10 Apr 2014 16:53:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=z1GafII/d+aCFTzLp6ATD6S4GHnO8F6fQ3t0nbCX/gY=; b=AOUYM1apsbxwt+mxE4Gd+QQMSbYtINlxx++iiI7fESJr5pFRdlC1c9uVZdnKtTbD8q 9g2T0Hgws7CZKJlzmMbVCEZm/kpWTtEp+fY/Ao9zo2qWS+1a8GdwjVl+RIel4loTQret VntamrTZ65vIiVJLLqOKJza0l0ePq87Pptl/xcXfJNLH958AB7yK3QjX4SM0ysxjyjdx 0K8XkzT4QUGhhSVz8VJxFTMoW85YC0OWq0vc6Kw1qDCgO/JGIyX+7i5l2UIy4DKsrKRw bLCv7pC+kaJE7Ps0p3jnrXLuHRTQFHPxSmGoO2g9GyQ/cE4Ropg4qsG4JanGsIiw/CXr QAVg== X-Received: by 10.66.254.234 with SMTP id al10mr23072192pad.137.1397173988177; Thu, 10 Apr 2014 16:53:08 -0700 (PDT) Received: from [192.168.2.226] (c-67-188-1-12.hsd1.ca.comcast.net. [67.188.1.12]) by mx.google.com with ESMTPSA id st4sm26904554pab.34.2014.04.10.16.53.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 10 Apr 2014 16:53:06 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Content-Type: text/plain; charset=iso-8859-1 From: Douglas Otis In-Reply-To: Date: Thu, 10 Apr 2014 16:53:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0C559F1B-6F5B-4357-AFC4-99E46DDCEBB8@gmail.com> References: <64E9ED15-A94D-4D80-9447-80C1E217E19A@gmail.com> <4DBFF820-72EE-4369-9837-AE15F81E5410@gmail.com> To: Dave Taht X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/5ITLy_pSdzU3OsoiiqabpyiqA0A Cc: HOMENET , Don Sturek , dnssd@ietf.org Subject: Re: [homenet] [dnssd] IETF-89 WG meeting minutes 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, 10 Apr 2014 23:53:10 -0000 On Apr 6, 2014, at 9:32 PM, Dave Taht wrote: > On Fri, Apr 4, 2014 at 8:08 AM, Douglas Otis = wrote: >>=20 >> On Apr 4, 2014, at 6:10 AM, Don Sturek wrote: >>=20 >> Hi Douglas, >>=20 >> As one who follows the WG and having a keen interest in homenet = solutions, >> I fail to see how TRILL addresses the homenet problem set. >>=20 >> Producing a flat L2 architecture and then trying to set up specific >> service filters to contain the traffic seems like an L3 problem to = me. >>=20 >> Claiming that L3 does not address "security threats" is not a reason = to >> use TRILL since I would imagine setting "specific service filters" in >> TRILL would have the same issues (and without the existing IETF L3 >> security solutions we already have) >>=20 >> Don >>=20 >> Dear Don, >>=20 >> Typical home networks could use link-local addresses for all internal >> devices without the filtering concern that effects enterprise level >> deployments. >=20 > The day that spanning tree or trill works well over wireless 802.11, > 802.14, lte, etc will be the day that I start thinking it's suitable > for home use. >=20 > If the DCB folk were to try implementing their stuff on 802.11 in > particular, with it's 1mbit/sec > multicast rate, perhaps we would come to a meeting of the minds. Dear Dave, Sorry for the delay. I am currently working on a security consideration = update. Data Center Bridging (for FCoE, etc), LTE (mobile wireless), 802.14 = (multiple services over Cable-TV systems using ATM QOS), or Shortest = Path Bridging (SPB per RFC6329) implemented with two ethernet = encapsulating data paths -- 802.1ad (Provider Bridges) and 802.1ah = (Provider Backbone Bridges). These technologies are within providers' = purview and not directly relevant to CPE. Nevertheless, within a home = or small office environment, Rbridge remains a viable incremental = solution for combining disparate technologies.=20 mDNS is not easily deployed at large scale over wireless without = filtering. Wifi has improved by offering mitigation strategies like = multicast queuing per N beacons and multicast specific filters. Even = so, these strategies are unlikely needed at home. I make extensive use = of mDNS within a dense wireless spectrum containing dozens of nearby = access points without difficulty while transferring multiple HD+ = streams. I would be interested in knowing what problems you are = experiencing within your home. Homenet documentation has largely ignored layer 2 protocols essential = for defining network boundaries and for offering typical services such = as remote displays. These essential functions can not be replaced by = any layer 3 strategy. As such, layer 2 must be included in any homenet = relevant security and operational consideration. >> In addition, the mDNS to DNS proxy scheme expects routable >> addresses and rather ugly name conversion and base domain assignments >> ignored in proposed specifications. >=20 > They are, at least, consistent. In expressing desires?=20 >> In comparison, Rbridge which can be introduced incrementally, permits >> continued use of link-local addressing and firewalls to avoid a = difficult >> task of assessing network boundaries. Devices using default mDNS = names >> would not suddenly become indirectly visible and various network = enabled >> displays that handle HDCP media still function within the home. >=20 > Service discovery and service access are different things. I don't = mind > (that much) if some larger subset of people than I really want can > see that a resource such as "TRACI LORDS PR0N COLLECTION" > exists on the network, so long only the right people can actually > access it. [1] If a local printer is made available via proxy mDNS exposure, there is = no way to secure it. Many devices cannot be updated, cannot be = secured, and do not offer authenticated or authorized-only access. = These are the kinds of issues that should be raised and discussed, even = if only in a BCP document. By using automatically assigned routable IP = addresses, thwarting stateful firewall protections becomes far easier. = Many devices not suitable for Internet exposure will suddenly lack the = benefit of only having the typical link-local address. For mDNS, a = service proves it resides on a local link by answering link-local = multicast queries. A proxy mDNS resource can never offer that assurance = nor can it be expected to. > But others may. >=20 > The scope of announcing that something exists may well need to be = restricted > somehow. >=20 >> Even if Rbridge is not a viable solution, I would still request that = we look >> at the security impact of any proposal - even if it is just in the = form of a >> BCP that would be useful for deployment. >=20 > I agree that security needs to be looked at harder in homenet and = dnssd. >=20 > I fail to see how rbridge solves anything from a security perspective > if you have home/guest lans, or any other natural division of link > layer technologies. The point of a guest LAN is to impose access barriers except to the = Internet. There are plenty of Internet services able to bridge between = two different realms. Such as cleaning up infected systems with only = access via a satellite link using UDP communications, for example. :^) > Please implement rbridge support over a busy wireless lan and > get back to us. We have implemented network enabled display access by using non-trivial = VLAN configurations well beyond what would be reasonable within a home. = Rbridge would have greatly eased configuration efforts. Recently = non-backward compatible changes have been implemented in Rbridge = extensions to better facilitate such efforts. Regards, Douglas Otis From nobody Fri Apr 11 00:01: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 3DCB71A041D; Thu, 10 Apr 2014 23:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 ezjrYMjpR7bf; Thu, 10 Apr 2014 23:41:52 -0700 (PDT) Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id E3DE21A03E2; Thu, 10 Apr 2014 23:41:51 -0700 (PDT) Received: by mail-qa0-f42.google.com with SMTP id k15so4963366qaq.15 for ; Thu, 10 Apr 2014 23:41:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=7/B8tpw7l9Af/gJy+TPZhPpKilwfwHubU6Esc//L2Mc=; b=aSpkr+rvKA4hnCgBj30QR/F+WYpzXW2pmobccn6DuT7XxamwVdDLfijEurh37s3tw9 XEwGMiDUXjxMKDr3Tj1Nh9YHlTtdklhLtd+lRdd5w2JGO3ADTwf/AAgSMHoivur36XAe 8PDl1gvwCCeAi/AntNlwtY1jt1GKB7PI81PRWWYj8e468C2Cyfy9iXDnw66dURs+ETvZ jlAi1pVey2SD35BNoK7GaJAeOb75C+weHD1bEoaamIolDOjxXFXoLD64gWb7yFYHH+Wk DbN9K4g8uyDii1hNAXLVTZRak9XsoqPU7xTzrxPuAIVoaRcXVmdVWi+zZeDg3u3omB0p Nbjg== X-Received: by 10.140.49.109 with SMTP id p100mr25013588qga.47.1397198510642; Thu, 10 Apr 2014 23:41:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.142.19 with HTTP; Thu, 10 Apr 2014 23:41:29 -0700 (PDT) In-Reply-To: <0C559F1B-6F5B-4357-AFC4-99E46DDCEBB8@gmail.com> References: <64E9ED15-A94D-4D80-9447-80C1E217E19A@gmail.com> <4DBFF820-72EE-4369-9837-AE15F81E5410@gmail.com> <0C559F1B-6F5B-4357-AFC4-99E46DDCEBB8@gmail.com> From: Henning Rogge Date: Fri, 11 Apr 2014 08:41:29 +0200 Message-ID: To: Douglas Otis Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/uIE2T_hCQdJ35mjHnNfLmAuSTRU X-Mailman-Approved-At: Fri, 11 Apr 2014 00:01:14 -0700 Cc: dnssd@ietf.org, HOMENET , Don Sturek , Dave Taht Subject: Re: [homenet] [dnssd] IETF-89 WG meeting minutes 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, 11 Apr 2014 06:41:53 -0000 On Fri, Apr 11, 2014 at 1:53 AM, Douglas Otis wrote= : > mDNS is not easily deployed at large scale over wireless without filterin= g. Wifi has improved by offering mitigation strategies like multicast queu= ing per N beacons and multicast specific filters. Even so, these strategie= s are unlikely needed at home. I make extensive use of mDNS within a dense= wireless spectrum containing dozens of nearby access points without diffic= ulty while transferring multiple HD+ streams. I would be interested in kno= wing what problems you are experiencing within your home. Its not only mDNS, its also ARP, ICMPv6 and other "linklocal multicast" protocols that work badly over large Wifi linklayer domains. Linklocal normally means "fast, cheap, atomic, in-order"... if you replace it with a large wireless layer-2 domain, it becomes something very different. Henning Rogge From nobody Mon Apr 14 08:00: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 6A2BF1A049E for ; Mon, 14 Apr 2014 08:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 Hb2lQuKJqV9Q for ; Mon, 14 Apr 2014 08:00:28 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 84EE71A04AA for ; Mon, 14 Apr 2014 08:00:22 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:2520:ef8a:477:622f]) by jazz.viagenie.ca (Postfix) with ESMTPSA id E145D403FF for ; Mon, 14 Apr 2014 11:00:19 -0400 (EDT) Message-ID: <534BF803.3090600@viagenie.ca> Date: Mon, 14 Apr 2014 11:00:19 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: homenet@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/BIDL3lPdZKFGSB7O4teDJTVWdbo Subject: [homenet] Please review the No IPv4 draft 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, 14 Apr 2014 15:00:30 -0000 Dearest HOMENET, We are soliciting reviews for this SUNSET4 draft: http://tools.ietf.org/html/draft-ietf-sunset4-noipv4-00 In a nutshell, it defines DHCPv6 and RA options indicating to the host that IPv4 is not available. Since home networks are among those likely to see its use, reviews coming from HOMENET would be of tremendous help. Thanks, Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Mon Apr 14 08:19: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 AD34C1A02CF for ; Mon, 14 Apr 2014 08:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.026 X-Spam-Level: X-Spam-Status: No, score=0.026 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_DK=1.009, MIME_8BIT_HEADER=0.3, MIME_HEADER_CTYPE_ONLY=0.717] 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 xr4ygrK1XK8L for ; Mon, 14 Apr 2014 08:19:36 -0700 (PDT) Received: from mail2.tohojo.dk (mail2.tohojo.dk [IPv6:2a01:4f8:200:3141::101]) by ietfa.amsl.com (Postfix) with ESMTP id 9E77F1A01BA for ; Mon, 14 Apr 2014 08:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at example.com Received: by alrua-kau.localdomain (Postfix, from userid 1000) id 32CF5BDAF5; Mon, 14 Apr 2014 17:19:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toke.dk; s=201310; t=1397488767; bh=d5anIcOiovzI4mqiDfiPtC6xg4QFsvM1ryW3QrYgRpE=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=GWNE10I8MB7vyAWMrULo54o7OsXV9pfjHgHgXyV8IlC7/fkFwUi65H0nnpmbJbPf8 +jUgfncfhyAUSlzATWcrw0aM3Q4Y5UtDkRs0OpsKopJsxn19kQkbCb26t1ncIbXnMO r3AP7YxxcA7w19WGAILog5KYhrY1Zw0WKnUmpVvI= From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= To: Simon Perreault In-Reply-To: <534BF803.3090600@viagenie.ca> (Simon Perreault's message of "Mon, 14 Apr 2014 11:00:19 -0400") References: <534BF803.3090600@viagenie.ca> Date: Mon, 14 Apr 2014 17:19:23 +0200 Message-ID: <87wqes3pms.fsf@toke.dk> Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/QN0r1fXjnkaXJPUOKF6mziRJSTA Cc: homenet@ietf.org Subject: Re: [homenet] Please review the No IPv4 draft 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, 14 Apr 2014 15:19:37 -0000 --=-=-= Content-Type: text/plain Simon Perreault writes: > In a nutshell, it defines DHCPv6 and RA options indicating to the host > that IPv4 is not available. Since home networks are among those likely > to see its use, reviews coming from HOMENET would be of tremendous > help. If I understand the draft correctly, a rogue user could completely disable connectivity for all hosts on the local link, simply by sending out a single RA message. Is that correct? (I am here thinking of the case of an IPv4 only network where the real router is not including this field in its DHCP/RA messages, but the clients understand it). -Toke --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBCAAGBQJTS/x7AAoJEENeEGz1+utP+asH/RTrrf3mrbCitI8z0X7MXNZf N4Ue0lcDBsAvEHzMY6YzklQYNwpo3cluAHB6L+gLggcdkuFiT0nsYHi+9wpeuDSi GeQn9P7aadWAdtY9O5R9p0Hb+4AaEur3oltrHBPYO0+nawVqsOS34AxyTFxBFpuj 6k2HtKJL+hKTWvWMQfW2XOCxHdBUpj12RnW3fuwgAUFne47K+Sr4mgVtb8nO+DMF 23iB/Fm0bDGuPOMSUa0nJPS95MqCQDdPeTWKknkEw20blpTclv2qcl2ssN3PDOdU n8sXWTPHaglOICXiBRaZLofnT3+MWZ0QWjKdq0cXkwf7AnSCvY/pOtiL9zsMFuY= =FoIu -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Apr 14 10:56:42 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 B89591A0515 for ; Mon, 14 Apr 2014 10:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.873 X-Spam-Level: X-Spam-Status: No, score=-1.873 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.272, 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 OQyNjOAVcQDW for ; Mon, 14 Apr 2014 10:56:36 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3D44A1A01FC for ; Mon, 14 Apr 2014 10:56:34 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:2520:ef8a:477:622f]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 78124403EF; Mon, 14 Apr 2014 13:56:31 -0400 (EDT) Message-ID: <534C214F.6010603@viagenie.ca> Date: Mon, 14 Apr 2014 13:56:31 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Toke_H=F8iland-J=F8rgensen?= References: <534BF803.3090600@viagenie.ca> <87wqes3pms.fsf@toke.dk> In-Reply-To: <87wqes3pms.fsf@toke.dk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/SmOGfPmy9M3RVPoiqL-wDI6r-0k Cc: homenet@ietf.org Subject: Re: [homenet] Please review the No IPv4 draft 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, 14 Apr 2014 17:56:40 -0000 Le 2014-04-14 11:19, Toke Høiland-Jørgensen a écrit : > If I understand the draft correctly, a rogue user could completely > disable connectivity for all hosts on the local link, simply by sending > out a single RA message. Is that correct? (I am here thinking of the > case of an IPv4 only network where the real router is not including this > field in its DHCP/RA messages, but the clients understand it). Correct. But if DHCP or RAs are not filtered at layer 2, a rogue user can already do this today without this extension. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Tue Apr 15 04:29: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 CD0861A03C4 for ; Tue, 15 Apr 2014 04:29:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.026 X-Spam-Level: X-Spam-Status: No, score=0.026 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_DK=1.009, MIME_8BIT_HEADER=0.3, MIME_HEADER_CTYPE_ONLY=0.717] 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 kMdI840O8GQB for ; Tue, 15 Apr 2014 04:28:58 -0700 (PDT) Received: from mail2.tohojo.dk (mail2.tohojo.dk [IPv6:2a01:4f8:200:3141::101]) by ietfa.amsl.com (Postfix) with ESMTP id C36841A02B2 for ; Tue, 15 Apr 2014 04:28:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at example.com Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id B7E551ECCC; Tue, 15 Apr 2014 13:28:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toke.dk; s=201310; t=1397561324; bh=Rx5jnTGXwOEHHvmOmNiTI7EjypFZ4qUNua/oAk3dgeo=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=kTHrzftYiBOwCPjtc28WElLwUz+m9wacpnZde6GanusrSX2wNemT1GqNzG7sPXf+D 6Hwkera2z+k8n/przKrAiNeUhjK+OLnXrFg7mozjh6rKIJ93e/ZjhXhXpB5upHmltq oeuxVU39AXKy7XAb5jWhJABdTR6XBpEfixtvZzmE= From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= To: Simon Perreault In-Reply-To: <534C214F.6010603@viagenie.ca> (Simon Perreault's message of "Mon, 14 Apr 2014 13:56:31 -0400") References: <534BF803.3090600@viagenie.ca> <87wqes3pms.fsf@toke.dk> <534C214F.6010603@viagenie.ca> Date: Tue, 15 Apr 2014 13:28:41 +0200 Message-ID: <878ur67rx2.fsf@toke.dk> Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/5ERPlCppcl6n_77yDingX3El_m8 Cc: homenet@ietf.org Subject: Re: [homenet] Please review the No IPv4 draft 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, 15 Apr 2014 11:29:02 -0000 --=-=-= Content-Type: text/plain Simon Perreault writes: > Correct. But if DHCP or RAs are not filtered at layer 2, a rogue user > can already do this today without this extension. Right, to a certain extent that is true, of course; but not in the same drive-by fashion where a single packet can put everyone offline (if the option is not in the regular announcements). Would it not be reasonable to add in a requirement that if a client has already received a DHCPv4 lease (or more generally, has been configured for IPv4 in some way), it will ignore requests to turn off the stack? -Toke --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBCAAGBQJTTRfpAAoJEENeEGz1+utPUhYIAMWgwl3rW12oXwtRHeDMFGaK x1rdPDpdQriEN1dyVAU5IZtdYAYPeCp2tZbecWxV3VgtcGBfro2c362/w+yxfZej Zzm8kCvkrsBGeTd30vz2oGF/OOq3lg5X5cnuncRZHYEjcm7DCiMUVxm8xCZkGptQ jV6arZKBhRxgfFf7H268D2XXniQ8/i1i4JPZtuT5lr/y7vDvB7wipiPK2n+OtolI 1AxdQNA7wkzgS8HiOflF65uBEs5H5e8mQ8dd9uwtTR/MhD423rG3bLExEj2yQFWu WGhq/yVck/suRboEZ3nj6mpMseF8F19GtwrZGfGsbJd0cFKdJ5z1XIHlMP9A3xI= =hFjU -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Apr 15 06: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 E46721A0712 for ; Tue, 15 Apr 2014 06:46:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.873 X-Spam-Level: X-Spam-Status: No, score=-1.873 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.272, 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 6BZWwFe9GyNL for ; Tue, 15 Apr 2014 06:46:49 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3CF321A07A8 for ; Tue, 15 Apr 2014 06:46:42 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:2520:ef8a:477:622f]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 3D189403E0; Tue, 15 Apr 2014 09:46:39 -0400 (EDT) Message-ID: <534D383E.2090602@viagenie.ca> Date: Tue, 15 Apr 2014 09:46:38 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Toke_H=F8iland-J=F8rgensen?= References: <534BF803.3090600@viagenie.ca> <87wqes3pms.fsf@toke.dk> <534C214F.6010603@viagenie.ca> <878ur67rx2.fsf@toke.dk> In-Reply-To: <878ur67rx2.fsf@toke.dk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/1_eeGk43KcVmtgjjqiY5Zpa-9Ac Cc: homenet@ietf.org Subject: Re: [homenet] Please review the No IPv4 draft 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, 15 Apr 2014 13:46:52 -0000 Le 2014-04-15 07:28, Toke Høiland-Jørgensen a écrit : > Simon Perreault writes: > >> Correct. But if DHCP or RAs are not filtered at layer 2, a rogue user >> can already do this today without this extension. > > Right, to a certain extent that is true, of course; but not in the same > drive-by fashion where a single packet can put everyone offline (if the > option is not in the regular announcements). Sure it can. Just send them to a non-existing default gateway. Unless I misunderstood your point. > Would it not be reasonable to add in a requirement that if a client has > already received a DHCPv4 lease (or more generally, has been configured > for IPv4 in some way), it will ignore requests to turn off the stack? I'd be fine with that. Thanks for the idea! Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Tue Apr 15 06:51:26 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 091BF1A0729 for ; Tue, 15 Apr 2014 06:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.026 X-Spam-Level: X-Spam-Status: No, score=0.026 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_DK=1.009, MIME_8BIT_HEADER=0.3, MIME_HEADER_CTYPE_ONLY=0.717] 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 TiXMqoHjmANI for ; Tue, 15 Apr 2014 06:51:19 -0700 (PDT) Received: from mail2.tohojo.dk (mail2.tohojo.dk [IPv6:2a01:4f8:200:3141::101]) by ietfa.amsl.com (Postfix) with ESMTP id EA2141A0706 for ; Tue, 15 Apr 2014 06:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at example.com Received: by alrua-kau.localdomain (Postfix, from userid 1000) id 18AEEC6116; Tue, 15 Apr 2014 15:51:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toke.dk; s=201310; t=1397569870; bh=tUq1GBXmWlxQJH2lTdJx0itgT1fhN7CoQLeMzGwQxSo=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=iwlvIOVHOquOD0Dvuh4pVb5TibnqZiVM1gcSDFk3aNBSDb800We0vAcxNu6TSvUta 9n8LUpKorE9jDJsASM9p5aSMMorTWKxmmaZ4z/u6N4rNzbh6wvlGxK+b+Uxnm5KryJ upgGDXIfKdlKmHdWvHnjlG+QICUMdUnasi0Re3yo= From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= To: Simon Perreault References: <534BF803.3090600@viagenie.ca> <87wqes3pms.fsf@toke.dk> <534C214F.6010603@viagenie.ca> <878ur67rx2.fsf@toke.dk> <534D383E.2090602@viagenie.ca> Date: Tue, 15 Apr 2014 15:51:06 +0200 In-Reply-To: <534D383E.2090602@viagenie.ca> (Simon Perreault's message of "Tue, 15 Apr 2014 09:46:38 -0400") Message-ID: <874n1uvgz9.fsf@toke.dk> Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/9WpBZWIcNo-3yqRZGW0yzRzeQGo Cc: homenet@ietf.org Subject: Re: [homenet] Please review the No IPv4 draft 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, 15 Apr 2014 13:51:23 -0000 --=-=-= Content-Type: text/plain Simon Perreault writes: > Sure it can. Just send them to a non-existing default gateway. Unless > I misunderstood your point. My point was that if you do this, the next time the real gateway sends out an advertisement, connections are going to be restored. Whereas if the gateway doesn't "speak" this option, all the hosts are just going to shut down IPv4 and not come back up until someone realises this is what happened. >> Would it not be reasonable to add in a requirement that if a client has >> already received a DHCPv4 lease (or more generally, has been configured >> for IPv4 in some way), it will ignore requests to turn off the stack? > > I'd be fine with that. Thanks for the idea! Cool! :) -Toke --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBCAAGBQJTTTlKAAoJEENeEGz1+utPjKkIAMQDLUxVCFFJDBgfxeJ526u5 Eah30SAH0B+yhtJAtjGdyyn/PGvtXgWoIuKaL2TUy+9R8yfhsLbtvpV6pgPzjsFF jRNGHGYpPPpa+79aD++kVERGjGElfV3lMfWRXJ9JVds+JxDRwmNA8sNHMOIysJnU uZ3SqE6rvVjt14ntJZmBHaBQBgmogX4S7kEYxKTJVOuGjh/3wJoJgsBcnmkuRr/g rTqSymZj0nVLYiIpPUb7T7ZIreWHAQQgENeik6X426ipnu0YLIlluRe9UDehQYO3 PIAFzUDe/A8sOt/3LvewzQO2Ar9aqgsa/EJRDoit17a2AGuPa366r1iEeQsIidQ= =NabC -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Apr 15 07:00: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 B35EA1A0213 for ; Tue, 15 Apr 2014 07:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.2 X-Spam-Level: X-Spam-Status: No, score=-6.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-2.3] 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 zThBQuAfOW0O for ; Tue, 15 Apr 2014 07:00:01 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 267A81A049A for ; Tue, 15 Apr 2014 07:00:01 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #76) id m1Wa3u1-0000DxC; Tue, 15 Apr 2014 15:59:57 +0200 Message-Id: To: Simon Perreault From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <534BF803.3090600@viagenie.ca> <87wqes3pms.fsf@toke.dk> <534C214F.6010603@viagenie.ca> <878ur67rx2.fsf@toke.dk> <534D383E.2090602@viagenie.ca> In-reply-to: Your message of "Tue, 15 Apr 2014 09:46:38 -0400 ." <534D383E.2090602@viagenie.ca> Date: Tue, 15 Apr 2014 15:59:57 +0200 Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/27EALHSrMCAjv5j2EkoFbBO7J-o Cc: homenet@ietf.org Subject: Re: [homenet] Please review the No IPv4 draft 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, 15 Apr 2014 14:00:12 -0000 In your letter dated Tue, 15 Apr 2014 09:46:38 -0400 you wrote: >Le 2014-04-15 07:28, Toke H=F8iland-J=F8rgensen a =E9crit : >> Simon Perreault writes: >> = > >>> Correct. But if DHCP or RAs are not filtered at layer 2, a rogue user >>> can already do this today without this extension. >> = > >> Right, to a certain extent that is true, of course; but not in the same >> drive-by fashion where a single packet can put everyone offline (if the >> option is not in the regular announcements). > >Sure it can. Just send them to a non-existing default gateway. Unless I >misunderstood your point. Right now, on any network that doesn't do IPv6, sending RAs has marginal effect. Certainly traffic within the site would be unaffected if there are no IPv6 addresses in DNS. With an RA that kills IPv4, that changes dramatically. Sounds like something no sane OS vendor would enable by default. >From an OS perspective, I'd rather have this option in DHCPv4. That part of the code knows about IPv4. Getting the IPv6 stack to tell the IPv4 stack to shutdown is complicated and probably won't be implemented until enough people bitch about it (and how stupid the IETF was) for quite some time. From nobody Tue Apr 15 07:07: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 2F8CB1A07D1 for ; Tue, 15 Apr 2014 07:07:06 -0700 (PDT) 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 g64Mr6odZSZp for ; Tue, 15 Apr 2014 07:07:04 -0700 (PDT) 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 D9D151A07D0 for ; Tue, 15 Apr 2014 07:07:03 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/46573) with ESMTP id s3FE70tl005115 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 15 Apr 2014 16:07:00 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/46573) with ESMTP id s3FE70DY004386; Tue, 15 Apr 2014 16:07:00 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 396D72CDC29; Tue, 15 Apr 2014 16:07:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 5rHsk8CFTY8s; Tue, 15 Apr 2014 16:06:58 +0200 (CEST) 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 2ED602CDC25; Tue, 15 Apr 2014 16:06:58 +0200 (CEST) Date: Tue, 15 Apr 2014 16:07:01 +0200 Message-ID: <87ha5u7kl6.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Simon Perreault In-Reply-To: <534BF803.3090600@viagenie.ca> References: <534BF803.3090600@viagenie.ca> 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, 15 Apr 2014 16:07:00 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Tue, 15 Apr 2014 16:07:00 +0200 (CEST) X-Miltered: at korolev with ID 534D3D04.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 534D3D04.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 534D3D04.002 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 534D3D04.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 : 534D3D04.002 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 534D3D04.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/O9zeBvS5PvCpWnzbgzMjpmyTd-w Cc: homenet@ietf.org Subject: Re: [homenet] Please review the No IPv4 draft 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, 15 Apr 2014 14:07:06 -0000 > We are soliciting reviews for this SUNSET4 draft: > > http://tools.ietf.org/html/draft-ietf-sunset4-noipv4-00 > > In a nutshell, it defines DHCPv6 and RA options indicating to the host > that IPv4 is not available. It seems to me that options relating to IPv4 don't belong in RA/DHCPv6 -- they belong in DHCPv4. Having a degenerate DHCPv4 server that just NAKs every request would appear to solve all of the problems in Section 3. The main point is that having a dedicated DHCPv4-NAK-ing server avoids the need to configure all IPv6 routers with IPv4-related information -- a serious operational concern if you have many IPv6 routers on a single link. (To be fair, you might need a new DHCPv4 option that says "do not try to contact any other DHCPv4 servers" to solve your problems 3.1/3.2. But then, I'd like to see some operational experience that shows that it is a problem in practice.) -- Juliusz (who wishes people would stop dumping gazillions of unrelated options into existing protocols) From nobody Tue Apr 15 08:15: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 7DC8C1A04BC for ; Tue, 15 Apr 2014 08:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.873 X-Spam-Level: X-Spam-Status: No, score=-1.873 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.272, 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 3Gewvtn1D6i4 for ; Tue, 15 Apr 2014 08:15:29 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 83B671A064A for ; Tue, 15 Apr 2014 08:15:29 -0700 (PDT) Received: from [172.16.0.175] (rrcs-67-78-65-202.sw.biz.rr.com [67.78.65.202]) by toccata.fugue.com (Postfix) with ESMTPSA id 4D1542380CB4; Tue, 15 Apr 2014 11:15:25 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: <878ur67rx2.fsf@toke.dk> Date: Tue, 15 Apr 2014 10:15:23 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <3F8F807A-AE0E-428A-A915-9D5CE8127F1A@fugue.com> References: <534BF803.3090600@viagenie.ca> <87wqes3pms.fsf@toke.dk> <534C214F.6010603@viagenie.ca> <878ur67rx2.fsf@toke.dk> To: =?windows-1252?Q?Toke_H=F8iland-J=F8rgensen?= X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/Mc2iwmLRJQw6zVCpNscbjQFM_jg Cc: homenet@ietf.org Subject: Re: [homenet] Please review the No IPv4 draft 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, 15 Apr 2014 15:15:35 -0000 On Apr 15, 2014, at 6:28 AM, Toke H=F8iland-J=F8rgensen = wrote: > Right, to a certain extent that is true, of course; but not in the = same > drive-by fashion where a single packet can put everyone offline (if = the > option is not in the regular announcements). This is a good point. Given that this draft depends on IPv6 = configuration that comes with lifetimes, it would make sense to specify = that the no-ipv4 configuration information is only valid for the = lifetime of the configuration message that delivered it=97e.g., the = prefix lifetime for RA, or the lease lifetime for DHCP, or for DHCP = information-requests, the information refresh timer interval. Since = we're doing the IPv6 configuration protocol anyway, there's no damage = done by continuing to rely on it to suppress IPv4 configuration. > Would it not be reasonable to add in a requirement that if a client = has > already received a DHCPv4 lease (or more generally, has been = configured > for IPv4 in some way), it will ignore requests to turn off the stack? No, because this just leaves the client open to a different DoS attack. = If you have rogue configuration protocols running on your network, you = need to fix it. This just moves the problem around=97it doesn't solve = it. One thing that I think would make this less likely to happen would be to = state that no-ipv4 must be present on all valid configuration states = received on a particular interface in order for no-ipv4 to be valid for = that interface. IOW, if you are getting rogue RAs that say "no IPv4" = and also a non-rogue RA that doesn't say "no IPv4," the host assumes = that IPv4 is permitted. This prevents a rogue RA from killing IPv4 = connectivity even for the lifetime of that RA. Of course the downside to this is that if you have multiple advertisers = on your link and they don't all agree, you lose, but again that's a = configuration error that the admin can fix, and hence not something that = needs to be addressed at a protocol level. From nobody Tue Apr 15 08:18: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 BE7B51A069A for ; Tue, 15 Apr 2014 08:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 4FXD30zOLi57 for ; Tue, 15 Apr 2014 08:18:01 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 219071A0492 for ; Tue, 15 Apr 2014 08:18:01 -0700 (PDT) Received: from [172.16.0.175] (rrcs-67-78-65-202.sw.biz.rr.com [67.78.65.202]) by toccata.fugue.com (Postfix) with ESMTPSA id 7E55A2380400; Tue, 15 Apr 2014 11:17:57 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: <87ha5u7kl6.wl%jch@pps.univ-paris-diderot.fr> Date: Tue, 15 Apr 2014 10:17:56 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <534BF803.3090600@viagenie.ca> <87ha5u7kl6.wl%jch@pps.univ-paris-diderot.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/ZEe7bavcMZz_ZntgRY8CmPIuL6A Cc: homenet@ietf.org Subject: Re: [homenet] Please review the No IPv4 draft 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, 15 Apr 2014 15:18:05 -0000 On Apr 15, 2014, at 9:07 AM, Juliusz Chroboczek = wrote: > Having a degenerate DHCPv4 server that just > NAKs every request would appear to solve all of the problems in = Section 3. Actually no, this would create packet storms. From nobody Tue Apr 15 08:24: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 01E081A01E2 for ; Tue, 15 Apr 2014 08:24:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 FOlj1hlQQZpA for ; Tue, 15 Apr 2014 08:24:51 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 675F71A014B for ; Tue, 15 Apr 2014 08:24:51 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:2520:ef8a:477:622f]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 5F61E4043F; Tue, 15 Apr 2014 11:24:48 -0400 (EDT) Message-ID: <534D4F40.5050102@viagenie.ca> Date: Tue, 15 Apr 2014 11:24:48 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Philip Homburg References: <534BF803.3090600@viagenie.ca> <87wqes3pms.fsf@toke.dk> <534C214F.6010603@viagenie.ca> <878ur67rx2.fsf@toke.dk> <534D383E.2090602@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/CNNlPWJXEVZnQrbbjG-jCA2ZUXw Cc: homenet@ietf.org Subject: Re: [homenet] Please review the No IPv4 draft 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, 15 Apr 2014 15:24:53 -0000 Le 2014-04-15 09:56, Philip Homburg a écrit : >>> Right, to a certain extent that is true, of course; but not in the same >>> drive-by fashion where a single packet can put everyone offline (if the >>> option is not in the regular announcements). >> >> Sure it can. Just send them to a non-existing default gateway. Unless I >> misunderstood your point. > > Right now, on any network that doesn't do IPv6, sending RAs has marginal > effect. Certainly traffic within the site would be unaffected if there are > no IPv6 addresses in DNS. > > With an RA that kills IPv4, that changes dramatically. Sounds like something > no sane OS vendor would enable by default. You can do the same today with a rogue DHCPv4 server. > From an OS perspective, I'd rather have this option in DHCPv4. That part > of the code knows about IPv4. Getting the IPv6 stack to tell the > IPv4 stack to shutdown is complicated Please tell me how this is complicated: $ grep "option no-ipv4" /var/db/dhclient6.leases.eth0 && pkill dhclient For the systems I know, it would be trivial to implement. I could go and submit a patch to NetworkManager today. > and probably won't be implemented > until enough people bitch about it (and how stupid the IETF was) for quite > some time. This is an argument that always comes back with any proposal. I totally disagree with it. Anyone could code this up and submit a patch to Android. Then when the next release happens, bam, lots of support overnight. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Tue Apr 15 08:27:45 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 C6CA21A0476 for ; Tue, 15 Apr 2014 08:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 5IGKnQ2l6YZ4 for ; Tue, 15 Apr 2014 08:27:39 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1B74C1A0201 for ; Tue, 15 Apr 2014 08:27:37 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:2520:ef8a:477:622f]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 1545C403C1; Tue, 15 Apr 2014 11:27:34 -0400 (EDT) Message-ID: <534D4FE5.8050909@viagenie.ca> Date: Tue, 15 Apr 2014 11:27:33 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Ted Lemon , Juliusz Chroboczek References: <534BF803.3090600@viagenie.ca> <87ha5u7kl6.wl%jch@pps.univ-paris-diderot.fr> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/7RgZWW-PaQu0laH-PhAu5tpQaZI Cc: homenet@ietf.org Subject: Re: [homenet] Please review the No IPv4 draft 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, 15 Apr 2014 15:27:44 -0000 Le 2014-04-15 11:17, Ted Lemon a écrit : > On Apr 15, 2014, at 9:07 AM, Juliusz Chroboczek wrote: >> Having a degenerate DHCPv4 server that just >> NAKs every request would appear to solve all of the problems in Section 3. > > Actually no, this would create packet storms. Correct, and just ignoring the requests would not make the clients shut up either. They periodically wake up and see if IPv4 has become available. There's no way to signal that IPv4 is not available. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Tue Apr 15 08:29: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 819D11A0176 for ; Tue, 15 Apr 2014 08:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 xM7NCcpPnU8b for ; Tue, 15 Apr 2014 08:29:06 -0700 (PDT) Received: from jenni1.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 3A8D11A0201 for ; Tue, 15 Apr 2014 08:29:05 -0700 (PDT) Received: from dock.lan (80.220.67.193) by jenni1.inet.fi (8.5.140.03) (authenticated as stenma-47) id 534D29300003887E; Tue, 15 Apr 2014 18:28:55 +0300 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Markus Stenberg In-Reply-To: <87ha5u7kl6.wl%jch@pps.univ-paris-diderot.fr> Date: Tue, 15 Apr 2014 18:28:53 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <9AD303C8-6B46-4589-BCE5-5A311AF5A4E4@iki.fi> References: <534BF803.3090600@viagenie.ca> <87ha5u7kl6.wl%jch@pps.univ-paris-diderot.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/iRZaWH4dsSh0YbaytolnbHhBDq8 Cc: homenet@ietf.org, Markus Stenberg Subject: Re: [homenet] Please review the No IPv4 draft 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, 15 Apr 2014 15:29:10 -0000 On 15.4.2014, at 17.07, Juliusz Chroboczek = wrote: >> We are soliciting reviews for this SUNSET4 draft: >>=20 >> http://tools.ietf.org/html/draft-ietf-sunset4-noipv4-00 >>=20 >> In a nutshell, it defines DHCPv6 and RA options indicating to the = host >> that IPv4 is not available. >=20 > It seems to me that options relating to IPv4 don't belong in RA/DHCPv6 > -- they belong in DHCPv4. Having a degenerate DHCPv4 server that just > NAKs every request would appear to solve all of the problems in = Section 3. > The main point is that having a dedicated DHCPv4-NAK-ing server avoids > the need to configure all IPv6 routers with IPv4-related information > -- a serious operational concern if you have many IPv6 routers on a = single > link. >=20 > (To be fair, you might need a new DHCPv4 option that says "do not try > to contact any other DHCPv4 servers" to solve your problems 3.1/3.2. > But then, I'd like to see some operational experience that shows that = it > is a problem in practice.) Disclaimer: I haven=92t read the draft. I like the idea on high level, = though. Certain not-quite-RFC-compliant DHCP clients send DISCOVER once = every 3 seconds until end of the world. I=92m not sure this would fix = those, though. NAK isn=92t probably what you want (due to it=92s semantics). However, = OFFER that doesn=92t really offer anything + magic option that says IPv4 = is dead is what I=92d want.=20 I would rather see this than RA options as well; that way, the DHCP = state machine (if any) can decide how long it honors this request not to = do stuff. It also keeps v4 and v6 decoupled which actually makes life = much easier in some implementations. Cheers, -Markus From nobody Tue Apr 15 08:34:37 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 3C8CD1A04AA for ; Tue, 15 Apr 2014 08:34:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.873 X-Spam-Level: X-Spam-Status: No, score=-1.873 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.272, 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 1bR2vFTk5nlT for ; Tue, 15 Apr 2014 08:34:31 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7A7141A0476 for ; Tue, 15 Apr 2014 08:34:31 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:2520:ef8a:477:622f]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 7792541172; Tue, 15 Apr 2014 11:34:28 -0400 (EDT) Message-ID: <534D5184.4040208@viagenie.ca> Date: Tue, 15 Apr 2014 11:34:28 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Ted Lemon , =?windows-1252?Q?Toke_H=F8iland-J=F8r?= =?windows-1252?Q?gensen?= References: <534BF803.3090600@viagenie.ca> <87wqes3pms.fsf@toke.dk> <534C214F.6010603@viagenie.ca> <878ur67rx2.fsf@toke.dk> <3F8F807A-AE0E-428A-A915-9D5CE8127F1A@fugue.com> In-Reply-To: <3F8F807A-AE0E-428A-A915-9D5CE8127F1A@fugue.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/gPgQfaR-ZT8iHu6oc7OxNzg5GGc Cc: homenet@ietf.org Subject: Re: [homenet] Please review the No IPv4 draft 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, 15 Apr 2014 15:34:36 -0000 Le 2014-04-15 11:15, Ted Lemon a écrit : > On Apr 15, 2014, at 6:28 AM, Toke Høiland-Jørgensen wrote: >> Right, to a certain extent that is true, of course; but not in the same >> drive-by fashion where a single packet can put everyone offline (if the >> option is not in the regular announcements). > > This is a good point. Given that this draft depends on IPv6 configuration that comes with lifetimes, it would make sense to specify that the no-ipv4 configuration information is only valid for the lifetime of the configuration message that delivered it—e.g., the prefix lifetime for RA, or the lease lifetime for DHCP, or for DHCP information-requests, the information refresh timer interval. Since we're doing the IPv6 configuration protocol anyway, there's no damage done by continuing to rely on it to suppress IPv4 configuration. Makes total sense. Will be added in the next revision. (One could even argue that this is implicit with any information received over DHCPv6 or RA, and that doing otherwise would be going against design principles of those protocols.) Thanks, Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Tue Apr 15 08:46: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 82BE41A06F7 for ; Tue, 15 Apr 2014 08:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.026 X-Spam-Level: X-Spam-Status: No, score=0.026 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_DK=1.009, MIME_8BIT_HEADER=0.3, MIME_HEADER_CTYPE_ONLY=0.717] 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 wkTrA5UZMaIK for ; Tue, 15 Apr 2014 08:46:20 -0700 (PDT) Received: from mail2.tohojo.dk (mail2.tohojo.dk [IPv6:2a01:4f8:200:3141::101]) by ietfa.amsl.com (Postfix) with ESMTP id A58261A044B for ; Tue, 15 Apr 2014 08:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at example.com Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id DDF511ED26; Tue, 15 Apr 2014 17:46:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toke.dk; s=201310; t=1397576767; bh=cR8+dc3Ay1kwefRk58p5Vsu6G7usiowbBsUkR+ocSGc=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=gLylBrMtZ2PhNd74KfcOP4OhNif6sTID7TuxDd4g6Xw/a2Mn0lrO4RzaT/gBqnAOD xIyy5BR0eU4b+ZCndjGcS31zBBhKfyx7K3yjMH81NdPzJud9a3Qu6FqOQ6chD+Xvum IGIOt2PF7Qu08b3jyUVleetyJvFW6ZfxR1WkzsLo= From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= To: Ted Lemon References: <534BF803.3090600@viagenie.ca> <87wqes3pms.fsf@toke.dk> <534C214F.6010603@viagenie.ca> <878ur67rx2.fsf@toke.dk> <3F8F807A-AE0E-428A-A915-9D5CE8127F1A@fugue.com> Date: Tue, 15 Apr 2014 17:46:04 +0200 In-Reply-To: <3F8F807A-AE0E-428A-A915-9D5CE8127F1A@fugue.com> (Ted Lemon's message of "Tue, 15 Apr 2014 10:15:23 -0500") Message-ID: <874n1u7g03.fsf@toke.dk> Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/Sd8RLEVUzZDgdu0WmmEFJJSRmJM Cc: homenet@ietf.org Subject: Re: [homenet] Please review the No IPv4 draft 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, 15 Apr 2014 15:46:24 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ted Lemon writes: > No, because this just leaves the client open to a different DoS > attack. If you have rogue configuration protocols running on your > network, you need to fix it. This just moves the problem around=E2=80=94it > doesn't solve it. Well, assuming this stays as an RA option and not a DHCPv4 one, I don't think it will be unreasonable for someone running an IPv4-only network to assume that they don't have to worry about IPv6 configuration protocols disabling their IPv4. Having the exception that if IPv4 already works, don't disable it will make this assumption more likely to be true. As an example, consider a university campus network (or a conference network) running IPv4 only, and someone broadcasting an RA packet onto the open wireless. Suddenly everything goes offline and will stay that way (until the RA expires) since no legitimate RAs come along to tell hosts to turn IPv4 back on. > One thing that I think would make this less likely to happen would be > to state that no-ipv4 must be present on all valid configuration > states received on a particular interface in order for no-ipv4 to be > valid for that interface. IOW, if you are getting rogue RAs that say > "no IPv4" and also a non-rogue RA that doesn't say "no IPv4," the host > assumes that IPv4 is permitted. This prevents a rogue RA from killing > IPv4 connectivity even for the lifetime of that RA. I would definitely think it would be a good idea to have "option not present" have the same semantics as "option set to allow ipv4". Otherwise, those actually running dual-stack networks would have to upgrade just to keep this from potentially causing problems. =2DToke --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBCAAGBQJTTVQ8AAoJEENeEGz1+utPUpYIALpwbbM9Kyf4ylMZ/xEhU9Co r70YVUj4IegZJx5HowEdOpubn2tDibEjo8+fBxPY1u3mpoOeQk7U0qlRHsBpkLgN c/18ojG+JRqiLpqgNsjT4ty47VwTsbInUmd+7lIK1uTSG+6p9QOiZqAgg6l2P9wU WaNllH86WrMAdvBM3cU3oUd7btFSQzxWK2vQYCP957ufcPWzG74DlHXeHmyh/773 +m4uZygh69h5bJCVEt8vG68pArjp/b+DXegGVKRf2dyX6p7TVTesAQh2IXaTpv9f q+5fvE0IMIs8DDRwkpys+RWh4sLWIhNz55EjqOovJiktHUHptMMQuHM3lXo3d8U= =jHVD -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Apr 15 08:48: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 CCBC31A011A for ; Tue, 15 Apr 2014 08:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.2 X-Spam-Level: X-Spam-Status: No, score=-6.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-2.3] 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 3Fbe_ExJAxFN for ; Tue, 15 Apr 2014 08:48:15 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 71F001A02CB for ; Tue, 15 Apr 2014 08:48:14 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #76) id m1Wa5al-0000BgC; Tue, 15 Apr 2014 17:48:11 +0200 Message-Id: To: Simon Perreault From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <534BF803.3090600@viagenie.ca> <87wqes3pms.fsf@toke.dk> <534C214F.6010603@viagenie.ca> <878ur67rx2.fsf@toke.dk> <534D383E.2090602@viagenie.ca> <534D4F40.5050102@viagenie.ca> In-reply-to: Your message of "Tue, 15 Apr 2014 11:24:48 -0400 ." <534D4F40.5050102@viagenie.ca> Date: Tue, 15 Apr 2014 17:48:10 +0200 Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/py2xYWTs5nUcDkI7SL47fA06ozU Cc: homenet@ietf.org Subject: Re: [homenet] Please review the No IPv4 draft 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, 15 Apr 2014 15:48:16 -0000 In your letter dated Tue, 15 Apr 2014 11:24:48 -0400 you wrote: >Le 2014-04-15 09:56, Philip Homburg a écrit : >>>> Right, to a certain extent that is true, of course; but not in the same >>>> drive-by fashion where a single packet can put everyone offline (if the >>>> option is not in the regular announcements). >>> >>> Sure it can. Just send them to a non-existing default gateway. Unless I >>> misunderstood your point. >> >> Right now, on any network that doesn't do IPv6, sending RAs has marginal >> effect. Certainly traffic within the site would be unaffected if there are >> no IPv6 addresses in DNS. >> >> With an RA that kills IPv4, that changes dramatically. Sounds like something >> no sane OS vendor would enable by default. > >You can do the same today with a rogue DHCPv4 server. No, you can't if the switches filter DHCP. DHCP also has a completely different failure mode than RAs. To subvert DHCP you have to wait for clients to send out DHCP discovers. For RA, you just broadcast a couple of RAs. A rogue DHCP server is annoying, but usually affects a few clients. A rogue RA affects then entire subnet. What you are doing is making IPv6 filtering mandatory on any network that wants to do just IPv4. >> From an OS perspective, I'd rather have this option in DHCPv4. That part >> of the code knows about IPv4. Getting the IPv6 stack to tell the >> IPv4 stack to shutdown is complicated > >Please tell me how this is complicated: > >$ grep "option no-ipv4" /var/db/dhclient6.leases.eth0 && pkill dhclient > >For the systems I know, it would be trivial to implement. I could go and >submit a patch to NetworkManager today. Yes, and by the time this is fully configurable, you are talking about many hundreds lines of code. You are not going to just kill your DHCPv4 client each time you receive a rogue RA. At least, not if you want people to use your OS. >> and probably won't be implemented >> until enough people bitch about it (and how stupid the IETF was) for quite >> some time. > >This is an argument that always comes back with any proposal. I totally >disagree with it. Anyone could code this up and submit a patch to >Android. Then when the next release happens, bam, lots of support overnight. Yes, and all security consultants will have a field day either selling patches to disable this or selling switches that can filter RAs. With your proposed code (actually killing dhclient) any mistake means that you have to reboot all systems in the affected LAN. Which means that any serious vendor will spend a lot of code making sure that the DHCP is only suspended for a couple of RA intervals, which leads to a way more complex interaction. From nobody Tue Apr 15 09:06:11 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 BD7761A07BD for ; Tue, 15 Apr 2014 09:06:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.173 X-Spam-Level: X-Spam-Status: No, score=-4.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RP_MATCHES_RCVD=-0.272, 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 2cWhz0bN-E9C for ; Tue, 15 Apr 2014 09:06:03 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id F2DD81A07B7 for ; Tue, 15 Apr 2014 09:06:02 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:2520:ef8a:477:622f]) by jazz.viagenie.ca (Postfix) with ESMTPSA id EE93E403C1; Tue, 15 Apr 2014 12:05:59 -0400 (EDT) Message-ID: <534D58E7.2050702@viagenie.ca> Date: Tue, 15 Apr 2014 12:05:59 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Philip Homburg References: <534BF803.3090600@viagenie.ca> <87wqes3pms.fsf@toke.dk> <534C214F.6010603@viagenie.ca> <878ur67rx2.fsf@toke.dk> <534D383E.2090602@viagenie.ca> <534D4F40.5050102@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/0jFsKSj2uHZNpoIi42NwQGTPeB8 Cc: homenet@ietf.org Subject: Re: [homenet] Please review the No IPv4 draft 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, 15 Apr 2014 16:06:08 -0000 Le 2014-04-15 11:48, Philip Homburg a écrit : > In your letter dated Tue, 15 Apr 2014 11:24:48 -0400 you wrote: >> Le 2014-04-15 09:56, Philip Homburg a écrit : >>>>> Right, to a certain extent that is true, of course; but not in the same >>>>> drive-by fashion where a single packet can put everyone offline (if the >>>>> option is not in the regular announcements). >>>> >>>> Sure it can. Just send them to a non-existing default gateway. Unless I >>>> misunderstood your point. >>> >>> Right now, on any network that doesn't do IPv6, sending RAs has marginal >>> effect. Certainly traffic within the site would be unaffected if there are >>> no IPv6 addresses in DNS. >>> >>> With an RA that kills IPv4, that changes dramatically. Sounds like something >>> no sane OS vendor would enable by default. >> >> You can do the same today with a rogue DHCPv4 server. > > No, you can't if the switches filter DHCP. > > DHCP also has a completely different failure mode than RAs. To subvert > DHCP you have to wait for clients to send out DHCP discovers. For RA, you > just broadcast a couple of RAs. > > A rogue DHCP server is annoying, but usually affects a few clients. A > rogue RA affects then entire subnet. > > What you are doing is making IPv6 filtering mandatory on any network that > wants to do just IPv4. I see your point. But that's already necessary today. Remember the SLAAC attack? http://resources.infosecinstitute.com/slaac-attack/ When you have unfiltered L2 access, there are LOTS of evil things you can do. >>> From an OS perspective, I'd rather have this option in DHCPv4. That part >>> of the code knows about IPv4. Getting the IPv6 stack to tell the >>> IPv4 stack to shutdown is complicated >> >> Please tell me how this is complicated: >> >> $ grep "option no-ipv4" /var/db/dhclient6.leases.eth0 && pkill dhclient >> >> For the systems I know, it would be trivial to implement. I could go and >> submit a patch to NetworkManager today. > > Yes, and by the time this is fully configurable, you are talking about many > hundreds lines of code. I completely disagree with your estimate. > You are not going to just kill your DHCPv4 client each time you receive a > rogue RA. > > At least, not if you want people to use your OS. Again: if there's an attacker with unfiltered L2 access to your host, there are lots of things he can do today to DoS you. >>> and probably won't be implemented >>> until enough people bitch about it (and how stupid the IETF was) for quite >>> some time. >> >> This is an argument that always comes back with any proposal. I totally >> disagree with it. Anyone could code this up and submit a patch to >> Android. Then when the next release happens, bam, lots of support overnight. > > Yes, and all security consultants will have a field day either selling patches > to disable this or selling switches that can filter RAs. > > With your proposed code (actually killing dhclient) any mistake means that > you have to reboot all systems in the affected LAN. No, you can just re-send the No-IPv4 option with value 0. We added it specifically to re-enable IPv4 when it has been previously disabled by mistake. And this is one advantage of using IPv6 for signalling the absence of IPv4 service. If you use IPv4 instead, and you make a mistake, there's no going back. > Which means that > any serious vendor will spend a lot of code making sure that the DHCP > is only suspended for a couple of RA intervals, which leads to a way > more complex interaction. As discussed with Ted Lemon, the next revision will specify that the No-IPv4 effect only lasts for the lifetime of DHCPv6 or RA. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Tue Apr 15 09:19: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 41C581A049C for ; Tue, 15 Apr 2014 09:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 Ebxqc5ttGxHf for ; Tue, 15 Apr 2014 09:19:03 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 8D5FC1A0641 for ; Tue, 15 Apr 2014 09:19:02 -0700 (PDT) Received: from [172.16.0.175] (rrcs-67-78-65-202.sw.biz.rr.com [67.78.65.202]) by toccata.fugue.com (Postfix) with ESMTPSA id 832832380400; Tue, 15 Apr 2014 12:18:52 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: <534D5184.4040208@viagenie.ca> Date: Tue, 15 Apr 2014 11:18:46 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <534BF803.3090600@viagenie.ca> <87wqes3pms.fsf@toke.dk> <534C214F.6010603@viagenie.ca> <878ur67rx2.fsf@toke.dk> <3F8F807A-AE0E-428A-A915-9D5CE8127F1A@fugue.com> <534D5184.4040208@viagenie.ca> To: Simon Perreault X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/Ps5T9S6J5bTlhYFoUZ06SDveOKo Cc: homenet@ietf.org Subject: Re: [homenet] Please review the No IPv4 draft 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, 15 Apr 2014 16:19:04 -0000 On Apr 15, 2014, at 10:34 AM, Simon Perreault = wrote: > Makes total sense. Will be added in the next revision. What about the other part? I think it works with the use model you have in mind: if you want some = devices to do IPv4 and others not, you can advertise "no IPv4" in the = RA, and send "no IPv4" by default in DHCP information requests, but send = nothing to clients that you want to use IPv4, and then the = attack-rejection heuristic I proposed would result in those clients = using IPv4. From nobody Tue Apr 15 09:22: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 6A3291A047D for ; Tue, 15 Apr 2014 09:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.873 X-Spam-Level: X-Spam-Status: No, score=-1.873 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.272, 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 RJxh9Qtiixi9 for ; Tue, 15 Apr 2014 09:22:35 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 152801A01BE for ; Tue, 15 Apr 2014 09:22:34 -0700 (PDT) Received: from [172.16.0.175] (rrcs-67-78-65-202.sw.biz.rr.com [67.78.65.202]) by toccata.fugue.com (Postfix) with ESMTPSA id 1CCA52380400; Tue, 15 Apr 2014 12:22:27 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: <874n1u7g03.fsf@toke.dk> Date: Tue, 15 Apr 2014 11:22:24 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <534BF803.3090600@viagenie.ca> <87wqes3pms.fsf@toke.dk> <534C214F.6010603@viagenie.ca> <878ur67rx2.fsf@toke.dk> <3F8F807A-AE0E-428A-A915-9D5CE8127F1A@fugue.com> <874n1u7g03.fsf@toke.dk> To: =?iso-8859-1?Q?Toke_H=F8iland-J=F8rgensen?= X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/_OZGWry6ScqgML8a_C2t4t5X8FQ Cc: homenet@ietf.org Subject: Re: [homenet] Please review the No IPv4 draft 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, 15 Apr 2014 16:22:44 -0000 On Apr 15, 2014, at 10:46 AM, Toke H=F8iland-J=F8rgensen = wrote: > As an example, consider a university campus network (or a conference > network) running IPv4 only, and someone broadcasting an RA packet onto > the open wireless. Suddenly everything goes offline and will stay that > way (until the RA expires) since no legitimate RAs come along to tell > hosts to turn IPv4 back on. Hm, okay, I guess that in order to address that use case you do need to = have a DHCPOFFER override an IPv6 "no IPv4" advertisement. However, = this still creates a timing race during which an attack could occur. = So I think that if you really want to prevent IPv4 being shut off on an = IPv4-only network by an RA, you really need to have your own RA going = out that offers no prefixes and doesn't say "no IPv4" or else you need = to filter IPv6 at layer 2 (which I tend to think is a really bad idea, = since it prevents ad-hoc link-local use of IPv6). From nobody Tue Apr 15 09:22: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 444251A0772 for ; Tue, 15 Apr 2014 09:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.873 X-Spam-Level: X-Spam-Status: No, score=-1.873 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.272, 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 aT3ABUyC4NuB for ; Tue, 15 Apr 2014 09:22:49 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1D0BF1A01D2 for ; Tue, 15 Apr 2014 09:22:49 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:2520:ef8a:477:622f]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 1425F4038F; Tue, 15 Apr 2014 12:22:46 -0400 (EDT) Message-ID: <534D5CD5.7050100@viagenie.ca> Date: Tue, 15 Apr 2014 12:22:45 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Ted Lemon , =?windows-1252?Q?Toke_H=F8iland-J=F8r?= =?windows-1252?Q?gensen?= References: <534BF803.3090600@viagenie.ca> <87wqes3pms.fsf@toke.dk> <534C214F.6010603@viagenie.ca> <878ur67rx2.fsf@toke.dk> <3F8F807A-AE0E-428A-A915-9D5CE8127F1A@fugue.com> In-Reply-To: <3F8F807A-AE0E-428A-A915-9D5CE8127F1A@fugue.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/McRapOnrxhMPD_3BJN3GwNxV1RM Cc: homenet@ietf.org Subject: Re: [homenet] Please review the No IPv4 draft 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, 15 Apr 2014 16:22:54 -0000 Sorry, missed an important part. Replying in full. Le 2014-04-15 11:15, Ted Lemon a écrit : > On Apr 15, 2014, at 6:28 AM, Toke Høiland-Jørgensen wrote: >> Right, to a certain extent that is true, of course; but not in the same >> drive-by fashion where a single packet can put everyone offline (if the >> option is not in the regular announcements). > > This is a good point. Given that this draft depends on IPv6 configuration that comes with lifetimes, it would make sense to specify that the no-ipv4 configuration information is only valid for the lifetime of the configuration message that delivered it—e.g., the prefix lifetime for RA, or the lease lifetime for DHCP, or for DHCP information-requests, the information refresh timer interval. Since we're doing the IPv6 configuration protocol anyway, there's no damage done by continuing to rely on it to suppress IPv4 configuration. Makes total sense. Will be added in the next revision. >> Would it not be reasonable to add in a requirement that if a client has >> already received a DHCPv4 lease (or more generally, has been configured >> for IPv4 in some way), it will ignore requests to turn off the stack? > > No, because this just leaves the client open to a different DoS attack. If you have rogue configuration protocols running on your network, you need to fix it. This just moves the problem around—it doesn't solve it. > > One thing that I think would make this less likely to happen would be to state that no-ipv4 must be present on all valid configuration states received on a particular interface in order for no-ipv4 to be valid for that interface. IOW, if you are getting rogue RAs that say "no IPv4" and also a non-rogue RA that doesn't say "no IPv4," the host assumes that IPv4 is permitted. This prevents a rogue RA from killing IPv4 connectivity even for the lifetime of that RA. So that means if you're running DHCPv6, and assuming you use RAs for provisioning at least the default gateway, you need to put the No-IPv4 option in both RA and DHCPv6. If we specify that then we could just kill the DHCPv6 option since it would then be useless. > Of course the downside to this is that if you have multiple advertisers on your link and they don't all agree, you lose, but again that's a configuration error that the admin can fix, and hence not something that needs to be addressed at a protocol level. Agreed. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Tue Apr 15 09:24: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 C386A1A01BE for ; Tue, 15 Apr 2014 09:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 rq-4HlzRZHKo for ; Tue, 15 Apr 2014 09:24:36 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id BFF2E1A016B for ; Tue, 15 Apr 2014 09:24:36 -0700 (PDT) Received: from [172.16.0.175] (rrcs-67-78-65-202.sw.biz.rr.com [67.78.65.202]) by toccata.fugue.com (Postfix) with ESMTPSA id E22ED2380400; Tue, 15 Apr 2014 12:24:32 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: <534D58E7.2050702@viagenie.ca> Date: Tue, 15 Apr 2014 11:24:31 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <534BF803.3090600@viagenie.ca> <87wqes3pms.fsf@toke.dk> <534C214F.6010603@viagenie.ca> <878ur67rx2.fsf@toke.dk> <534D383E.2090602@viagenie.ca> <534D4F40.5050102@viagenie.ca> <534D58E7.2050702@viagenie.ca> To: Simon Perreault X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/z2jYz8kvN1ZEhdTT9c8Ly7JxAL0 Cc: homenet@ietf.org, Philip Homburg Subject: Re: [homenet] Please review the No IPv4 draft 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, 15 Apr 2014 16:24:37 -0000 On Apr 15, 2014, at 11:05 AM, Simon Perreault = wrote: >> Yes, and by the time this is fully configurable, you are talking = about many >> hundreds lines of code. >=20 > I completely disagree with your estimate. I think you are talking apples and oranges. Simon, you are assuming a = functional configuration environment; in such an environment, the change = would be fairly trivial. Philip, I think you are assuming the current = status quo on linux, which is badly broken and requires massive amounts = of work to make small changes. In that context, it probably is = hundreds of lines of code. But that really needs to get fixed regardless of the outcome of this = discussion. From nobody Tue Apr 15 09:26: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 D4ABF1A07B6 for ; Tue, 15 Apr 2014 09:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 5V1a-gCraqHJ for ; Tue, 15 Apr 2014 09:26:07 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 44DB81A01BE for ; Tue, 15 Apr 2014 09:26:07 -0700 (PDT) Received: from [172.16.0.175] (rrcs-67-78-65-202.sw.biz.rr.com [67.78.65.202]) by toccata.fugue.com (Postfix) with ESMTPSA id C568C2380400; Tue, 15 Apr 2014 12:25:57 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: <534D5CD5.7050100@viagenie.ca> Date: Tue, 15 Apr 2014 11:25:55 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <6DA1CF10-41D9-4606-B10E-988A3B65A092@fugue.com> References: <534BF803.3090600@viagenie.ca> <87wqes3pms.fsf@toke.dk> <534C214F.6010603@viagenie.ca> <878ur67rx2.fsf@toke.dk> <3F8F807A-AE0E-428A-A915-9D5CE8127F1A@fugue.com> <534D5CD5.7050100@viagenie.ca> To: Simon Perreault X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/X_E_Qwt84tY79GoRUPvsZN01kPg Cc: homenet@ietf.org Subject: Re: [homenet] Please review the No IPv4 draft 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, 15 Apr 2014 16:26:09 -0000 On Apr 15, 2014, at 11:22 AM, Simon Perreault = wrote: > So that means if you're running DHCPv6, and assuming you use RAs for > provisioning at least the default gateway, you need to put the No-IPv4 > option in both RA and DHCPv6. If we specify that then we could just = kill > the DHCPv6 option since it would then be useless. No, the DHCPv6 option is useful for selectively enabling IPv4. From nobody Tue Apr 15 09:32: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 D85721A02E0 for ; Tue, 15 Apr 2014 09:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 qzBbjiArUjCN for ; Tue, 15 Apr 2014 09:32:42 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF591A01C8 for ; Tue, 15 Apr 2014 09:32:42 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:2520:ef8a:477:622f]) by jazz.viagenie.ca (Postfix) with ESMTPSA id ED09840063; Tue, 15 Apr 2014 12:32:38 -0400 (EDT) Message-ID: <534D5F26.9010506@viagenie.ca> Date: Tue, 15 Apr 2014 12:32:38 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Ted Lemon References: <534BF803.3090600@viagenie.ca> <87wqes3pms.fsf@toke.dk> <534C214F.6010603@viagenie.ca> <878ur67rx2.fsf@toke.dk> <3F8F807A-AE0E-428A-A915-9D5CE8127F1A@fugue.com> <534D5CD5.7050100@viagenie.ca> <6DA1CF10-41D9-4606-B10E-988A3B65A092@fugue.com> In-Reply-To: <6DA1CF10-41D9-4606-B10E-988A3B65A092@fugue.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/j6dXnceNx-WY3xMZ61TOkuvtgPE Cc: homenet@ietf.org Subject: Re: [homenet] Please review the No IPv4 draft 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, 15 Apr 2014 16:32:44 -0000 Le 2014-04-15 12:25, Ted Lemon a écrit : > On Apr 15, 2014, at 11:22 AM, Simon Perreault wrote: >> So that means if you're running DHCPv6, and assuming you use RAs for >> provisioning at least the default gateway, you need to put the No-IPv4 >> option in both RA and DHCPv6. If we specify that then we could just kill >> the DHCPv6 option since it would then be useless. > > No, the DHCPv6 option is useful for selectively enabling IPv4. Wait wait wait. If I get what you mean: - RAs would always contain No-IPv4. - DHCPv6 would selectively contain No-IPv4 or not. Is that correct? It can work. But it's sooo ugly! And I can just imagine the headaches it could cause to a sysadmin trying to troubleshoot a connectivity issue... Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Tue Apr 15 09:34: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 9E54B1A01BE for ; Tue, 15 Apr 2014 09:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2] 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 KhMxXHqg5kLM for ; Tue, 15 Apr 2014 09:34:51 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id C961D1A0584 for ; Tue, 15 Apr 2014 09:34:49 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #76) id m1Wa6Jq-0000AdC; Tue, 15 Apr 2014 18:34:46 +0200 Message-Id: To: Simon Perreault From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <534BF803.3090600@viagenie.ca> <87wqes3pms.fsf@toke.dk> <534C214F.6010603@viagenie.ca> <878ur67rx2.fsf@toke.dk> <534D383E.2090602@viagenie.ca> <534D4F40.5050102@viagenie.ca> <534D58E7.2050702@viagenie.ca> In-reply-to: Your message of "Tue, 15 Apr 2014 12:05:59 -0400 ." <534D58E7.2050702@viagenie.ca> Date: Tue, 15 Apr 2014 18:34:36 +0200 Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/JYTNdbpt45vn_14LZYaVLNYNC-A Cc: homenet@ietf.org Subject: Re: [homenet] Please review the No IPv4 draft 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, 15 Apr 2014 16:34:56 -0000 In your letter dated Tue, 15 Apr 2014 12:05:59 -0400 you wrote: >http://resources.infosecinstitute.com/slaac-attack/ > >When you have unfiltered L2 access, there are LOTS of evil things you >can do. The world is not black and white. Rogue RAs are easy for hit and run attacks. Maybe I should already create 'ipv4begone'. Would be a nice way to reserve the wireless for yourself in busy wifi networks. In contract MITM attacks are much harder to pull off. Any don't really gain much compared to just sniffing the wifi. >No, you can just re-send the No-IPv4 option with value 0. We added it >specifically to re-enable IPv4 when it has been previously disabled by >mistake. So now, any RA daemon also has to know to start dhclient. So it is more than just your oneliner. >And this is one advantage of using IPv6 for signalling the absence of >IPv4 service. If you use IPv4 instead, and you make a mistake, there's >no going back. Not if you just suspend DHCP operation for a while... >> Which means that >> any serious vendor will spend a lot of code making sure that the DHCP >> is only suspended for a couple of RA intervals, which leads to a way >> more complex interaction. > >As discussed with Ted Lemon, the next revision will specify that the >No-IPv4 effect only lasts for the lifetime of DHCPv6 or RA. Similar to what you describe here. There is of course an easy way out. Let this run its course and then write an informational RFC that allocates the required option for DHCPv4. More choices are always better... Let the OS vendors decide. From nobody Tue Apr 15 09:43: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 878381A01CB; Tue, 15 Apr 2014 09:43:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 Dp2ANTac83mC; Tue, 15 Apr 2014 09:43:15 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.252.184]) by ietfa.amsl.com (Postfix) with ESMTP id BE6741A01BE; Tue, 15 Apr 2014 09:43:14 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id D245620030; Tue, 15 Apr 2014 12:43:27 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 59F8763ABA; Tue, 15 Apr 2014 12:43:06 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 472BB63AA2; Tue, 15 Apr 2014 12:43:06 -0400 (EDT) From: Michael Richardson To: v6ops@ietf.org, Ted Lemon , homenet@ietf.org, sunset4@ietf.org In-Reply-To: <3F8F807A-AE0E-428A-A915-9D5CE8127F1A@fugue.com> References: <534BF803.3090600@viagenie.ca> <87wqes3pms.fsf@toke.dk> <534C214F.6010603@viagenie.ca> <878ur67rx2.fsf@toke.dk> <3F8F807A-AE0E-428A-A915-9D5CE8127F1A@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 Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/sMt2wgIOKKIx3vxeo3u-V5dd1R8 Subject: Re: [homenet] Please review the No IPv4 draft 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, 15 Apr 2014 16:43:19 -0000 I think it's important to read the draft, and understand section 5.3, about the "v4-level". I think that the security implications in the document are understood by the authors, but simply not spelled out yet. I think that some additional text in 5.3 might help make it clearer that there might be competing v4-labels coming from different routers/DHCPv6 servers, and that really the one with the lowest value wins. Hosts that don't understand this option will continue to behave as if the option did not occur, and any device for which this option is implemented needs to think about how much credence they will put into it. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ From nobody Tue Apr 15 09:47: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 5B4201A01F8 for ; Tue, 15 Apr 2014 09:47:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2] 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 ZZdatc5lmMMm for ; Tue, 15 Apr 2014 09:47:14 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id EE8751A07DD for ; Tue, 15 Apr 2014 09:47:11 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #76) id m1Wa6Vj-0000BmC; Tue, 15 Apr 2014 18:47:03 +0200 Message-Id: To: Ted Lemon From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <534BF803.3090600@viagenie.ca> <87wqes3pms.fsf@toke.dk> <534C214F.6010603@viagenie.ca> <878ur67rx2.fsf@toke.dk> <534D383E.2090602@viagenie.ca> <534D4F40.5050102@viagenie.ca> <534D58E7.2050702@viagenie.ca> In-reply-to: Your message of "Tue, 15 Apr 2014 11:24:31 -0500 ." Date: Tue, 15 Apr 2014 18:47:03 +0200 Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/-uhRgBSQVvD-71NnqeAnw7vbNJM Cc: homenet@ietf.org Subject: Re: [homenet] Please review the No IPv4 draft 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, 15 Apr 2014 16:47:18 -0000 In your letter dated Tue, 15 Apr 2014 11:24:31 -0500 you wrote: >I think you are talking apples and oranges. Simon, you are assuming a functio >nal configuration environment; in such an environment, the change would be fair >ly trivial. Philip, I think you are assuming the current status quo on linux, > which is badly broken and requires massive amounts of work to make small chang >es. In that context, it probably is hundreds of lines of code. > >But that really needs to get fixed regardless of the outcome of this discussion >. I'm also thinking about the code base for an embedded system I maintain. And I can really do without more complex interactions between IPv6 and IPv4. Adding an IPv4 suspend option to DHCPv4, that's easy. Doing the same thing from IPv6 is a nightmare. In any system that does DHCPv4, suspending IPv4 for a while is a purely local interaction with the DHCPc4 client. If you implement it for the most common DHCPv4 clients, you can probably get it implemented in little time. On the other hand, if you need have RAs signal suspend and resume of IPv4 you are looking at rewriting the management code of lots of different Linux distibutions (including various embedded ones) and many operating systems. From nobody Tue Apr 15 09:52: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 C03CB1A02E0 for ; Tue, 15 Apr 2014 09:51:56 -0700 (PDT) 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 1cI6NT_J8dT1 for ; Tue, 15 Apr 2014 09:51:56 -0700 (PDT) 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 DF0591A01CB for ; Tue, 15 Apr 2014 09:51:55 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/46573) with ESMTP id s3FGpnOL012177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 15 Apr 2014 18:51:49 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/46573) with ESMTP id s3FGpnV6008484; Tue, 15 Apr 2014 18:51:49 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id F37632CDC42; Tue, 15 Apr 2014 18:51:48 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id djLHZFBEb8vC; Tue, 15 Apr 2014 18:51:33 +0200 (CEST) Received: from lanthane.pps.univ-paris-diderot.fr (unknown [172.23.36.54]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id A3C072CDC34; Tue, 15 Apr 2014 18:51:32 +0200 (CEST) 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 1Wa6a4-00054c-Ec; Tue, 15 Apr 2014 18:51:32 +0200 Date: Tue, 15 Apr 2014 18:51:32 +0200 Message-ID: <7i1twyk02z.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Ted Lemon In-Reply-To: References: <534BF803.3090600@viagenie.ca> <87ha5u7kl6.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 [IPv6:2001:660:3301:8000::1:2]); Tue, 15 Apr 2014 18:51:49 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Tue, 15 Apr 2014 18:51:49 +0200 (CEST) X-Miltered: at korolev with ID 534D63A5.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 534D63A5.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 534D63A5.001 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 534D63A5.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 : 534D63A5.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 534D63A5.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/CQjISNqsPe1qXQ7HY4RnYqZslAA Cc: homenet@ietf.org Subject: Re: [homenet] Please review the No IPv4 draft 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, 15 Apr 2014 16:51:57 -0000 > > Having a degenerate DHCPv4 server that just NAKs every request > > would appear to solve all of the problems in Section 3. > Actually no, this would create packet storms. My bad -- I didn't actually check. So either an empty OFFER, as suggested by Markus, or an OFFER with a new *DHCPv4* option. -- Juliusz From nobody Tue Apr 15 10:06: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 4901F1A0642 for ; Tue, 15 Apr 2014 10:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 hKJPugHg6Ls9 for ; Tue, 15 Apr 2014 10:06:19 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 30C691A01F8 for ; Tue, 15 Apr 2014 10:06:19 -0700 (PDT) Received: from [192.168.146.119] (unknown [70.114.139.95]) by toccata.fugue.com (Postfix) with ESMTPSA id 872F12380CB4; Tue, 15 Apr 2014 13:06:15 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: <534D5F26.9010506@viagenie.ca> Date: Tue, 15 Apr 2014 12:06:14 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1FC795A8-DD82-457F-9EBC-6E31FD8272EF@fugue.com> References: <534BF803.3090600@viagenie.ca> <87wqes3pms.fsf@toke.dk> <534C214F.6010603@viagenie.ca> <878ur67rx2.fsf@toke.dk> <3F8F807A-AE0E-428A-A915-9D5CE8127F1A@fugue.com> <534D5CD5.7050100@viagenie.ca> <6DA1CF10-41D9-4606-B10E-988A3B65A092@fugue.com> <534D5F26.9010506@viagenie.ca> To: Simon Perreault X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/QiNyRRulbqjJJUpGaydp9Hmb7es Cc: homenet@ietf.org Subject: Re: [homenet] Please review the No IPv4 draft 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, 15 Apr 2014 17:06:20 -0000 On Apr 15, 2014, at 11:32 AM, Simon Perreault = wrote: > It can work. But it's sooo ugly! And I can just imagine the headaches = it > could cause to a sysadmin trying to troubleshoot a connectivity = issue... Sure, but imagine the headaches of a sysadmin trying to figure out why = IPv4 isn't working if we don't do it this way. From nobody Tue Apr 15 10:10: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 286DA1A01F8 for ; Tue, 15 Apr 2014 10:09:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 RvUJJP3xVswa for ; Tue, 15 Apr 2014 10:09:52 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 8A1D01A0760 for ; Tue, 15 Apr 2014 10:09:52 -0700 (PDT) Received: from [192.168.146.119] (unknown [70.114.139.95]) by toccata.fugue.com (Postfix) with ESMTPSA id 763572380CB4; Tue, 15 Apr 2014 13:09:49 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: Date: Tue, 15 Apr 2014 12:09:48 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <534BF803.3090600@viagenie.ca> <87wqes3pms.fsf@toke.dk> <534C214F.6010603@viagenie.ca> <878ur67rx2.fsf@toke.dk> <534D383E.2090602@viagenie.ca> <534D4F40.5050102@viagenie.ca> <534D58E7.2050702@viagenie.ca> To: Philip Homburg X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/5ri3KfVE-9tfAccBXWttAWJlMUw Cc: homenet@ietf.org Subject: Re: [homenet] Please review the No IPv4 draft 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, 15 Apr 2014 17:09:57 -0000 On Apr 15, 2014, at 11:47 AM, Philip Homburg = wrote: > On the other hand, if you need have RAs signal suspend and resume of = IPv4 > you are looking at rewriting the management code of lots of different = Linux > distibutions (including various embedded ones) and many operating = systems. Yes. That will be a really good outcome. I'm sorry, but I have no sympathy for your protestations about DHCPv4 = clients in embedded applications. If it's an RPi, you can run a = full-featured DHCPv4/DHCPv6 implementation that works, so there's no = excuse for running one that doesn't. If it's a tiny sensor, you want = to use 6lowpan anyway, so you're not running DHCPv4 _or_ DHCPv6. And = you also always have the option of just ignoring the option if you are = implementing something that really is an edge case. From nobody Tue Apr 15 10:30: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 49DCD1A01DC for ; Tue, 15 Apr 2014 10:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2] 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 P-VpbyGV7vL8 for ; Tue, 15 Apr 2014 10:29:54 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 18D4A1A01E7 for ; Tue, 15 Apr 2014 10:29:53 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #76) id m1Wa7B6-0000BhC; Tue, 15 Apr 2014 19:29:48 +0200 Message-Id: To: Ted Lemon From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <534BF803.3090600@viagenie.ca> <87wqes3pms.fsf@toke.dk> <534C214F.6010603@viagenie.ca> <878ur67rx2.fsf@toke.dk> <534D383E.2090602@viagenie.ca> <534D4F40.5050102@viagenie.ca> <534D58E7.2050702@viagenie.ca> In-reply-to: Your message of "Tue, 15 Apr 2014 12:09:48 -0500 ." Date: Tue, 15 Apr 2014 19:29:47 +0200 Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/PfRaLeb37zaX3vBD55URiIYSEs8 Cc: homenet@ietf.org Subject: Re: [homenet] Please review the No IPv4 draft 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, 15 Apr 2014 17:29:59 -0000 In your letter dated Tue, 15 Apr 2014 12:09:48 -0500 you wrote: >On Apr 15, 2014, at 11:47 AM, Philip Homburg wro >te: >> On the other hand, if you need have RAs signal suspend and resume of IPv4 >> you are looking at rewriting the management code of lots of different Linux >> distibutions (including various embedded ones) and many operating systems. > >Yes. That will be a really good outcome. You really think people are going to rewrite Linux network config for some weird edge case? >I'm sorry, but I have no sympathy for your protestations about DHCPv4 clients i >n embedded applications. If it's an RPi, you can run a full-featured DHCPv4/D >HCPv6 implementation that works, so there's no excuse for running one that does >n't. If it's a tiny sensor, you want to use 6lowpan anyway, so you're not run >ning DHCPv4 _or_ DHCPv6. And you also always have the option of just ignoring > the option if you are implementing something that really is an edge case. Then you don't. I'm only saying that from my perspective, changing DHCPv4 is the best technical solution. Now of course, the IETF can pick the option that requires serious changes in many operating systems, creates very interesting attacks, etc. Then that's just too bad. Note, this is an edge case. Operating systems hardly benefit from this option, but they will get the full load of any security issues. So my guess is that staying on the RA/DHCPv6 route will just seriously delay the implementation of this option. From nobody Tue Apr 15 11:20:29 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 B288D1A01FE for ; Tue, 15 Apr 2014 11:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 uNAUhmFkBHFC for ; Tue, 15 Apr 2014 11:20:24 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 26A8F1A0376 for ; Tue, 15 Apr 2014 11:20:24 -0700 (PDT) Received: from [192.168.146.119] (unknown [70.114.139.95]) by toccata.fugue.com (Postfix) with ESMTPSA id C6F172380CB4; Tue, 15 Apr 2014 14:20:20 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: Date: Tue, 15 Apr 2014 13:20:19 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <9068E42F-3E85-4D2F-AB57-234365CFE1C7@fugue.com> References: <534BF803.3090600@viagenie.ca> <87wqes3pms.fsf@toke.dk> <534C214F.6010603@viagenie.ca> <878ur67rx2.fsf@toke.dk> <534D383E.2090602@viagenie.ca> <534D4F40.5050102@viagenie.ca> <534D58E7.2050702@viagenie.ca> To: Philip Homburg X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/DtsSIfWfGR-58TEfpefSYIdUo1o Cc: homenet@ietf.org Subject: Re: [homenet] Please review the No IPv4 draft 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, 15 Apr 2014 18:20:28 -0000 On Apr 15, 2014, at 12:29 PM, Philip Homburg = wrote: > You really think people are going to rewrite Linux network config for = some > weird edge case? People are rewriting Linux the network configuration system as we speak. = This particular edge case is just one example of why it's broken. So = yes, I agree that if this were the only reason to do the work, it would = never happen, but since it's happening already, I think that's moot. > I'm only saying that from my perspective, changing DHCPv4 is the best=20= > technical solution. Right, but you haven't given a technical argument to support that. = You've just said that it's convenient in a particular existing = implementation, which is not in wide use, and which is already = undergoing changes that will coincidentally make addressing this less = inconvenient. So this isn't a good argument. > So my guess is that staying on the RA/DHCPv6 route will just seriously > delay the implementation of this option. On Linux. If neither systemd nor dnsmasq nor one of their replacements = actually becomes popular (although dnsmasq is already popular in = embedded environments). I agree with this, if you accept the caveats I = just added, but I don't think it's a big problem. From nobody Tue Apr 15 14:51:36 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 00A341A0781 for ; Tue, 15 Apr 2014 14:51:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.2 X-Spam-Level: X-Spam-Status: No, score=-6.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-2.3] 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 af8IKbWuUkau for ; Tue, 15 Apr 2014 14:51:33 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id DF60B1A077A for ; Tue, 15 Apr 2014 14:51:32 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #76) id m1WaBGI-0000BgC; Tue, 15 Apr 2014 23:51:26 +0200 Message-Id: To: Ted Lemon , homenet@ietf.org From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <534BF803.3090600@viagenie.ca> <87wqes3pms.fsf@toke.dk> <534C214F.6010603@viagenie.ca> <878ur67rx2.fsf@toke.dk> <534D383E.2090602@viagenie.ca> <534D4F40.5050102@viagenie.ca> <534D58E7.2050702@viagenie.ca> <9068E42F-3E85-4D2F-AB57-234365CFE1C7@fugue.com> In-reply-to: Your message of "Tue, 15 Apr 2014 13:20:19 -0500 ." <9068E42F-3E85-4D2F-AB57-234365CFE1C7@fugue.com> Date: Tue, 15 Apr 2014 23:51:26 +0200 Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/ZmIz4WIhZRFmcHNwRoG8BuGlTYI Subject: Re: [homenet] Please review the No IPv4 draft 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, 15 Apr 2014 21:51:35 -0000 In your letter dated Tue, 15 Apr 2014 13:20:19 -0500 you wrote: >Right, but you haven't given a technical argument to support that. >You've just said that it's convenient in a particular existing >implementation, which is not in wide use, and which is already >undergoing changes that will coincidentally make addressing this less >inconvenient. So this isn't a good argument. Please describe how in OSX, OpenWRT, FreeBSD, Android, IOS, the various Windows version gracefully starting and stopping IPv4 from an RA works? Oh, maybe give one example of a documented clean architecture that can handle this including every possible boundary condition. In contrast, having a DHCPv4 client stop sending DISCOVERs upon reception of a particular reply packet is almost a no brainer. I guess you don't see this as a technical argument, so be it. If you think that introducing network protocol changes that can only be handled by a widely used OS by rewriting their network config is a good idea when there is an alternative the can be implemented cleanly today, then there is no point further arguing. From nobody Tue Apr 15 16:55: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 3FB271A0063 for ; Tue, 15 Apr 2014 16:55:54 -0700 (PDT) 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 Qz5-7hcnYqse for ; Tue, 15 Apr 2014 16:55:52 -0700 (PDT) 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 720D91A0062 for ; Tue, 15 Apr 2014 16:55:52 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/46573) with ESMTP id s3FNtjSK032512 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 16 Apr 2014 01:55:45 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/46573) with ESMTP id s3FNtiWY022374; Wed, 16 Apr 2014 01:55:45 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id A834E1356E; Wed, 16 Apr 2014 01:55:44 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id i-iUdY_6xmOW; Wed, 16 Apr 2014 01:55:43 +0200 (CEST) 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 7C0622CC0B3; Wed, 16 Apr 2014 01:55:43 +0200 (CEST) Date: Wed, 16 Apr 2014 01:55:48 +0200 Message-ID: <87fvlep2pn.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Ted Lemon In-Reply-To: <9068E42F-3E85-4D2F-AB57-234365CFE1C7@fugue.com> References: <534BF803.3090600@viagenie.ca> <87wqes3pms.fsf@toke.dk> <534C214F.6010603@viagenie.ca> <878ur67rx2.fsf@toke.dk> <534D383E.2090602@viagenie.ca> <534D4F40.5050102@viagenie.ca> <534D58E7.2050702@viagenie.ca> <9068E42F-3E85-4D2F-AB57-234365CFE1C7@fugue.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]); Wed, 16 Apr 2014 01:55:46 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Wed, 16 Apr 2014 01:55:45 +0200 (CEST) X-Miltered: at korolev with ID 534DC701.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 534DC700.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 534DC701.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 534DC700.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 : 534DC701.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 534DC700.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/a8PsS_RTXJgy5mZ1FhSmlOOohbs Cc: homenet@ietf.org, Philip Homburg Subject: Re: [homenet] Please review the No IPv4 draft 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, 15 Apr 2014 23:55:54 -0000 >> I'm only saying that from my perspective, changing DHCPv4 is the best >> technical solution. > Right, but you haven't given a technical argument to support that. You're being somewhat disingeneous here, Ted. We're arguing that information about IPv4 availability should not be carried by IPv6 RAs, since it avoids a number of very unpleasant incestuous interactions. That is most certainly a "technical" argument, however you care to define this particular term. Keeping the two stacks cleanly separated has a number of practical ("technical"?) advantages: - in modular operating systems (not only Linux), this avoids dodgy interactions between separate daemons; - administrators can debug IPv4 issues without having to delve into the IPv6 configuration, and vice versa; - once (if?) IPv4 is phased out, we won't need to carry obsolete IPv4-related options within the IPv6 protocols. -- Juliusz From nobody Tue Apr 15 17:29: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 AD1081A006C for ; Tue, 15 Apr 2014 17:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, GB_I_LETTER=-2, RP_MATCHES_RCVD=-0.272, 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 LjLRbK0xcE8o for ; Tue, 15 Apr 2014 17:29:39 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id BCA571A0015 for ; Tue, 15 Apr 2014 17:29:38 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id 8420B2383E2; Wed, 16 Apr 2014 00:29:23 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id D1233160067; Wed, 16 Apr 2014 00:31:29 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 8418B160060; Wed, 16 Apr 2014 00:31:28 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 1FBA013CD524; Wed, 16 Apr 2014 10:28:51 +1000 (EST) To: Philip Homburg From: Mark Andrews References: <534BF803.3090600@viagenie.ca> <87wqes3pms.fsf@toke.dk> <534C214F.6010603@viagenie.ca> <878ur67rx2.fsf@toke.dk> <534D383E.2090602@viagenie.ca> <534D4F40.5050102@viagenie.ca> <534D58E7.2050702@viagenie.ca> <9068E42F-3E85-4D2F-AB57-234365CFE1C7@fugue.com> In-reply-to: Your message of "Tue, 15 Apr 2014 23:51:26 +0200." Date: Wed, 16 Apr 2014 10:28:51 +1000 Message-Id: <20140416002851.1FBA013CD524@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/2an1L3QyHnKm6NJnf2Xqfo-z0Zg Cc: homenet@ietf.org, Ted Lemon Subject: Re: [homenet] Please review the No IPv4 draft 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, 16 Apr 2014 00:29:43 -0000 In message , Philip Homburg writes: > In your letter dated Tue, 15 Apr 2014 13:20:19 -0500 you wrote: > >Right, but you haven't given a technical argument to support that. > >You've just said that it's convenient in a particular existing > >implementation, which is not in wide use, and which is already > >undergoing changes that will coincidentally make addressing this less > >inconvenient. So this isn't a good argument. > > Please describe how in OSX, OpenWRT, FreeBSD, Android, IOS, the various > Windows version gracefully starting and stopping IPv4 from an RA works? They write code. There is already userland code that reacts to RA flags in FreeBSD to start dhcpv6. It's not hard to add yet another callback to stop/start dhcpv4. I suspect if I sat down to do this I could do code it in a day. This is not rocket science. I could do it from scratch with raw sockets in just about as much time. I just need to be able to see the RA's and know what interface they arrived on. I have code in nameservers that listens for interface changes on routing sockets and adjusts manages the sockets that the nameserver listens on. That took well under a day to write from scratch and is about as complicated. This is not hard to implement. I would presume the others are roughly the same when you have access to the development trees. > Oh, maybe give one example of a documented clean architecture that can > handle this including every possible boundary condition. > > In contrast, having a DHCPv4 client stop sending DISCOVERs upon reception of > a particular reply packet is almost a no brainer. > > I guess you don't see this as a technical argument, so be it. > > If you think that introducing network protocol changes that can only be handl > ed > by a widely used OS by rewriting their network config is a good idea when > there is an alternative the can be implemented cleanly today, then there > is no point further arguing. > > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Tue Apr 15 17:55: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 173851A008F for ; Tue, 15 Apr 2014 17:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.163 X-Spam-Level: X-Spam-Status: No, score=-2.163 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=0.01] 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 FVkRSR3Qu_8W for ; Tue, 15 Apr 2014 17:55:26 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.252.184]) by ietfa.amsl.com (Postfix) with ESMTP id 8E5D71A0051 for ; Tue, 15 Apr 2014 17:55:26 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id C0D902003B; Tue, 15 Apr 2014 20:55:38 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id AEA5863ABA; Tue, 15 Apr 2014 20:55:19 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 9BEED63A9E; Tue, 15 Apr 2014 20:55:19 -0400 (EDT) From: Michael Richardson To: Philip Homburg In-Reply-To: References: <534BF803.3090600@viagenie.ca> <87wqes3pms.fsf@toke.dk> <534C214F.6010603@viagenie.ca> <878ur67rx2.fsf@toke.dk> <534D383E.2090602@viagenie.ca> <534D4F40.5050102@viagenie.ca> <534D58E7.2050702@viagenie.ca> <9068E42F-3E85-4D2F-AB57-234365CFE1C7@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 Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/gVM4LxGVjahLTpYuORSdwFMbcts Cc: homenet@ietf.org, Ted Lemon Subject: Re: [homenet] Please review the No IPv4 draft 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, 16 Apr 2014 00:55:31 -0000 --=-=-= Honestly, the decoupling of Wifi, IPv4 and IPv6 address configuration in Linux, OpenWRT, and FreeBSD is really a mistake, and it's gotta stop. It's a bug, not a feature. I left out OSX, Android, IOS and Windows from your list on purpose. My understanding is that OSX and IOS actually already do extensive coupling of layer-2 and layer-3 configurations, such that one can actually do things like recognize that the the layer-3 network configuration(s) on a particular ESSID is broken, and pick another ESSID. I know that there are interactions between IPv4 and IPv6 configurations on Windows *ALREADY*, but I can't give you the details. As for Android, as someone who has been deep into the code, there is so little IPv6 code in there at all, there isn't really anything to replace. There are multiple ways to couple things sensibly. On OpenWRT, dnsmasq is pretty much doing it all already. On Linux desktops, dbus and NetworkManager is there. Many don't like NM, but it's getting better. So that leaves FreeBSD. Remember: you don't have to implement this. Where it matters most is on home routers; where failing to turn off IPv4/recognize there-is-none, results in being on an IPv4 NOTwork. {I didn't buy the argument that people doing IPv6 didn't want to run IPv4 DHCP, at first, but slowly I've gotten to understand the numerous layer-2 and layer-3 savings by not having to have the whole DHCPv4 relay and broadcast processing occuring. DHCPv4 is not a young protocol...} -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBU03U94qHRg3pndX9AQL4VgP/a6ErpmWPAYlQwLykK/y362ZFjDkMWlTd 3d6bVLaDmVw5+gsGMWeJ4SMGFwBWKTmGcV0L37iRARtrSPF69OmvOcaYDsDWfjvs JKtOAoHkcGHS+Pmn2rwcoh7n40Wj9lZZv3aG1ZxVOQAwTP3De3Soi0ehYt2f6clw uUsDB1IQPaI= =V437 -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Apr 15 18:00: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 B3A321A0092 for ; Tue, 15 Apr 2014 18:00:11 -0700 (PDT) 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 RkET0zAF9UYF for ; Tue, 15 Apr 2014 18:00:11 -0700 (PDT) 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 CF5DD1A008F for ; Tue, 15 Apr 2014 18:00:10 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/46573) with ESMTP id s3G107Q0008548; Wed, 16 Apr 2014 03:00:07 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 2D18413576; Wed, 16 Apr 2014 03:00:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id OMEwuvdxTySn; Wed, 16 Apr 2014 02:59:51 +0200 (CEST) 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 AF5962CC0B3; Wed, 16 Apr 2014 02:59:51 +0200 (CEST) Date: Wed, 16 Apr 2014 02:59:57 +0200 Message-ID: <8761maozqq.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Michael Richardson In-Reply-To: <4631.1397609719@sandelman.ca> References: <534BF803.3090600@viagenie.ca> <87wqes3pms.fsf@toke.dk> <534C214F.6010603@viagenie.ca> <878ur67rx2.fsf@toke.dk> <534D383E.2090602@viagenie.ca> <534D4F40.5050102@viagenie.ca> <534D58E7.2050702@viagenie.ca> <9068E42F-3E85-4D2F-AB57-234365CFE1C7@fugue.com> <4631.1397609719@sandelman.ca> 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]); Wed, 16 Apr 2014 03:00:07 +0200 (CEST) X-Miltered: at korolev with ID 534DD617.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 534DD617.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 : 534DD617.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/lbK5H3gE_CbZGDJwhX0JwCJQfhM Cc: homenet@ietf.org Subject: Re: [homenet] Please review the No IPv4 draft 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, 16 Apr 2014 01:00:11 -0000 > slowly I've gotten to understand the numerous layer-2 and layer-3 > savings by not having to have the whole DHCPv4 relay and broadcast > processing occuring. Could you please explain that? Perhaps with some examples, or even actual empirical data? -- Juliusz From nobody Tue Apr 15 19:41: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 0C36F1A0029 for ; Tue, 15 Apr 2014 19:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.163 X-Spam-Level: X-Spam-Status: No, score=-2.163 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=0.01] 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 aOpPympqQifD for ; Tue, 15 Apr 2014 19:41:04 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id D673D1A002A for ; Tue, 15 Apr 2014 19:41:03 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id A99A72003B for ; Tue, 15 Apr 2014 22:41:19 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 9D90263ABA; Tue, 15 Apr 2014 22:40:59 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 8A21663A9E for ; Tue, 15 Apr 2014 22:40:59 -0400 (EDT) From: Michael Richardson To: homenet@ietf.org In-Reply-To: <8761maozqq.wl%jch@pps.univ-paris-diderot.fr> References: <534BF803.3090600@viagenie.ca> <87wqes3pms.fsf@toke.dk> <534C214F.6010603@viagenie.ca> <878ur67rx2.fsf@toke.dk> <534D383E.2090602@viagenie.ca> <534D4F40.5050102@viagenie.ca> <534D58E7.2050702@viagenie.ca> <9068E42F-3E85-4D2F-AB57-234365CFE1C7@fugue.com> <4631.1397609719@sandelman.ca> <8761maozqq.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 Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/IvDYMdLsZ7O-Jgw-4hhh3hONqvM Subject: Re: [homenet] Please review the No IPv4 draft 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, 16 Apr 2014 02:41:09 -0000 --=-=-= Juliusz Chroboczek wrote: >> slowly I've gotten to understand the numerous layer-2 and layer-3 >> savings by not having to have the whole DHCPv4 relay and broadcast >> processing occuring. > Could you please explain that? Perhaps with some examples, or even > actual empirical data? I'm not a large scale residential ISP, and I've never played one on TV, but I've operated niche ISPs since 1991, and recently installed a few medium sized business oriented DSL, Fiber and GPONs. GPONs are odd. I refer you to the sunset4 mailing list archives, but let me see what I recall. 1) Let's start with PPPoE/DSL No DHCPv4 server for IPv4, it's all done in PPP. So you'd have to have a DHCP server somehow, or a new PPP option. 2) Cable/FTTH using ethernet-type things. You need code (silicon actually, at FTTH speeds) to police DHCP traffic coming from each customer to make sure that they aren't running a rogue DHCPv4 server. That's something you can get rid of if you aren't running v4. You need to have DHCPv4 relay agents in each of your cable head ends, and they need to add option-82 to indicate where things are coming from. You'd like to turn off layer-2 broadcasts (ff:ff:ff:ff:ff:ff) because there is just a huge amount of noise coming from the customer machines, but you can't just do that because the DHCPv4 uses that, and you've got multiple layers of fiber backhauled cable modem. There is a significant ARP load on the network from every single box where 0.0.0.0/0->"eth0" because the network isn't configured yet. (Every single directly connected windows box does this, and some distros of Linux do this. I was surprised to learn it's allowed...) The broadcasts have actually forced you to subnet your IPv4 down into rather small pieces to contain it, and this has lead to uneven provisioning of IPv4 address space, and you've effectively run out. (Also see the history behind ARIN https://www.arin.net/policy/proposals/2012_7.html and http://www.crtc.gc.ca/eng/archive/2012/2012-96.htm might also be relevant) If you could turn off broadcasts, you could forward just the multicast you need (DHCPv6, RA..) which would significantly help reduce the MAC address load on much layer-2 equipment. Moreso, it's pretty much all P2MP traffic, so perhaps a much simpler layer-2 forwarding system could be used. (I don't have such a thing; legacy layer-3 assumptions wouldn't let anyone create such a thing yet) And again: if it's too hard, don't implement it (certainly not in open source, for free), thousands of devices will never get updated to have it anyway. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBU03tu4qHRg3pndX9AQK9VQP/eCjMOXPZFMTpRwjpf0gzwXaGsFlVnoFp 7v1hsQXmk7v8jOqATf6t1jnrZ7+uSSm3tkD5z8lcVY+8PheHdoJKByXpu/Ui0tRT VF9oFcaNLNbhgGhP0L/71YqAd25szzMo2fU0nCyADP9LP56RBqQO5yL42/178VqH dLxQL9kmha4= =Wd0l -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Apr 15 20:17: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 CE84C1A00D8 for ; Tue, 15 Apr 2014 20:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 REE3uEVM6G5c for ; Tue, 15 Apr 2014 20:17:13 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 9A9571A009E for ; Tue, 15 Apr 2014 20:17:13 -0700 (PDT) Received: from [192.168.146.119] (unknown [70.114.139.95]) by toccata.fugue.com (Postfix) with ESMTPSA id 322322380CB4; Tue, 15 Apr 2014 23:17:08 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: <87fvlep2pn.wl%jch@pps.univ-paris-diderot.fr> Date: Tue, 15 Apr 2014 22:17:07 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <534BF803.3090600@viagenie.ca> <87wqes3pms.fsf@toke.dk> <534C214F.6010603@viagenie.ca> <878ur67rx2.fsf@toke.dk> <534D383E.2090602@viagenie.ca> <534D4F40.5050102@viagenie.ca> <534D58E7.2050702@viagenie.ca> <9068E42F-3E85-4D2F-AB57-234365CFE1C7@fugue.com> <87fvlep2pn.wl%jch@pps.univ-paris-diderot.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/3P2Pzk-7svtWGGFgfF_VDsqIuLc Cc: homenet@ietf.org, Philip Homburg Subject: Re: [homenet] Please review the No IPv4 draft 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, 16 Apr 2014 03:17:16 -0000 On Apr 15, 2014, at 6:55 PM, Juliusz Chroboczek = wrote: > You're being somewhat disingeneous here, Ted. No, I'm really not. > We're arguing that information about IPv4 availability should not be > carried by IPv6 RAs, since it avoids a number of very unpleasant > incestuous interactions. That is most certainly a "technical" = argument, > however you care to define this particular term. It's not a valid technical objection. The working group thought about = the question, came to a conclusion, which is not the one you are = advocating, and you haven't said anything that indicates that their = conclusion was wrong, because they considered the solution you are = proposing and decided that a different solution was better. A technical objection is "this won't work because FOO." What is FOO? From nobody Tue Apr 15 23:49:03 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 79E6B1A0085 for ; Tue, 15 Apr 2014 23:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.773 X-Spam-Level: X-Spam-Status: No, score=-0.773 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.272, 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 08SZbb3S7DBH for ; Tue, 15 Apr 2014 23:48:57 -0700 (PDT) Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6CEA61A006B for ; Tue, 15 Apr 2014 23:48:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id BA1CB870074; Wed, 16 Apr 2014 08:48:53 +0200 (CEST) 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 6rWVkOtQBHQj; Wed, 16 Apr 2014 08:48:53 +0200 (CEST) Received: from Rays-iMac.local (092-111-140-211.static.chello.nl [92.111.140.211]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id 6FE97870073; Wed, 16 Apr 2014 08:48:53 +0200 (CEST) Message-ID: <534E27D2.3010401@globis.net> Date: Wed, 16 Apr 2014 08:48:50 +0200 From: Ray Hunter User-Agent: Postbox 3.0.9 (Macintosh/20140129) MIME-Version: 1.0 To: Michael Richardson References: <534BF803.3090600@viagenie.ca> <87wqes3pms.fsf@toke.dk> <534C214F.6010603@viagenie.ca> <878ur67rx2.fsf@toke.dk> <534D383E.2090602@viagenie.ca> <534D4F40.5050102@viagenie.ca> <534D58E7.2050702@viagenie.ca> <9068E42F-3E85-4D2F-AB57-234365CFE1C7@fugue.com> <4631.1397609719@sandelman.ca> <8761maozqq.wl%jch@pps.univ-paris-diderot.fr> <28578.1397616059@sandelman.ca> In-Reply-To: <28578.1397616059@sandelman.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/y4mJKHxFq13Afz_gkw-skLIzPe0 Cc: homenet@ietf.org Subject: Re: [homenet] Please review the No IPv4 draft 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, 16 Apr 2014 06:49:02 -0000 The alternative scenarios and management models for sunsetting do not seem to have been discussed: e.g. 1) allow a customer to run their own home router and control their own broadcast traffic and multicast traffic. With IPv6 there's no reason why stacked routers are harmful, because there's no NAT going on 2) ISP to provide an additional IPv6 only CPE router at the perimeter of the L2 broadcast network, again to limit the broadcast domain 3) to filter using MAC + DHCPv4 black hole addresses 4) to use an out of band management protocol such as active directory to turn off IPv4 in the kernel 5) to request users manual disable IPv4 when contracting the new IPv6 only service 6) tolerate the noise and let IPv4 die a natural death 7) provide separate logical networks for IPv6 only users and legacy IPv4 users 8) allow IPv4 to exist as individual disconnected islands Michael Richardson wrote: > > > And again: if it's too hard, don't implement it (certainly not in open > source, for free), thousands of devices will never get updated to have it anyway. > > -- > Michael Richardson, Sandelman Software Works > -= IPv6 IoT consulting =- > > That's rather disingenuous. The justification for this solution seems to be based on a very myopic view of the Internet. What may happen is that something like this may be implemented (because it's good for the particular ISPs that heavily rely on large L2 networks) whereas it does not benefit people who route everything (other ISP's and enterprises or home users who manage their own routers and thus broadcast domain.) Large and small enterprises will then have to scramble to filter rogue IPv6 DHCPv6 servers, even if they aren't running IPv6 yet internally on their networks, and their switches are probably too old to support RA Guard. They'll also want a kill switch on the kill switch in the OS. 'shutdown -h now' as a DHCPv6 option? That's effectively what's being proposed AFAICS. Why can't I continue to run IPv4 in the privacy of my own home (as an Island)? RFC 6724 will ensure that IPv6 is preferred for all off site traffic. -- Regards, RayH From nobody Wed Apr 16 01: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 718F01A0041 for ; Wed, 16 Apr 2014 01:19:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.2 X-Spam-Level: X-Spam-Status: No, score=-6.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-2.3] 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 WRLWe6OlpTMo for ; Wed, 16 Apr 2014 01:19:33 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 65B1B1A0027 for ; Wed, 16 Apr 2014 01:19:33 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #76) id m1WaL46-0000BeC; Wed, 16 Apr 2014 10:19:30 +0200 Message-Id: To: homenet@ietf.org From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <534BF803.3090600@viagenie.ca> <87wqes3pms.fsf@toke.dk> <534C214F.6010603@viagenie.ca> <878ur67rx2.fsf@toke.dk> <534D383E.2090602@viagenie.ca> <534D4F40.5050102@viagenie.ca> <534D58E7.2050702@viagenie.ca> <9068E42F-3E85-4D2F-AB57-234365CFE1C7@fugue.com> <4631.1397609719@sandelman.ca> <8761maozqq.wl%jch@pps.univ-paris-diderot.fr> <28578.1397616059@sandelman.ca> In-reply-to: Your message of "Tue, 15 Apr 2014 22:40:59 -0400 ." <28578.1397616059@sandelman.ca> Date: Wed, 16 Apr 2014 10:19:30 +0200 Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/Q0rhPEEB0CgFfYgqoguzGOL2MCU Subject: Re: [homenet] Please review the No IPv4 draft 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, 16 Apr 2014 08:19:38 -0000 In your letter dated Tue, 15 Apr 2014 22:40:59 -0400 you wrote: >I'm not a large scale residential ISP, and I've never played one on TV, but >I've operated niche ISPs since 1991, and recently installed a few medium >sized business oriented DSL, Fiber and GPONs. GPONs are odd. > >I refer you to the sunset4 mailing list archives, but let me see what I recall. > >1) Let's start with PPPoE/DSL > No DHCPv4 server for IPv4, it's all done in PPP. > So you'd have to have a DHCP server somehow, or a new PPP option. Maybe this is very the scope got overly broad. There is an easy way to signal the lack of IPv4 on PPP: just don't do IPCP. Note that signalling the lack of IPv4 in DHCPv6 over ppp when the CPE already started handing out rfc-1918 address by DHCP leads to very confusing interactions. >2) Cable/FTTH using ethernet-type things. > You need code (silicon actually, at FTTH speeds) to police DHCP traffic > coming from each customer to make sure that they aren't running a rogue > DHCPv4 server. > That's something you can get rid of if you aren't running v4. > You need to have DHCPv4 relay agents in each of your cable head ends, > and they need to add option-82 to indicate where things are coming from. > > You'd like to turn off layer-2 broadcasts (ff:ff:ff:ff:ff:ff) because > there is just a huge amount of noise coming from the customer machines, > but you can't just do that because the DHCPv4 uses that, and you've > got multiple layers of fiber backhauled cable modem. > There is a significant ARP load on the network from every single box > where 0.0.0.0/0->"eth0" because the network isn't configured yet. > (Every single directly connected windows box does this, and some distros > of Linux do this. I was surprised to learn it's allowed...) > > The broadcasts have actually forced you to subnet your IPv4 down into > rather small pieces to contain it, and this has lead to uneven > provisioning of IPv4 address space, and you've effectively run out. > (Also see the history behind ARIN > https://www.arin.net/policy/proposals/2012_7.html and > http://www.crtc.gc.ca/eng/archive/2012/2012-96.htm might also be relevant) > > If you could turn off broadcasts, you could forward just the multicast you > need (DHCPv6, RA..) which would significantly help reduce the MAC address > load on much layer-2 equipment. Moreso, it's pretty much all P2MP > traffic, so perhaps a much simpler layer-2 forwarding system could be > used. (I don't have such a thing; legacy layer-3 assumptions wouldn't let > anyone create such a thing yet) So the options are - - Just drop all ethernet broadcasts. They are not needed for IPv6 anyhow. problem solved. - - Give them IPv4 addresses without default routes. That clearly signals lack of IPv4 connectivity beyond the local subnet. - - Implement a DHCPv4 option that asks the DHCPv4 to not configure a link local address. That kills all ARP traffic and reduces DHCP traffic (though not configuring link local is less ideal from an security point of view) - - Redesign how ethernet broadcast works in those networks. I.e. treat ethernet broadcast as a special mac that needs to be routed towards the core. Problem solved. In any case, all these try to solve the problems directly instead of the rounabout way of using IPv6 to signal lack IPv4. From nobody Wed Apr 16 01:44: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 7091F1A0087 for ; Wed, 16 Apr 2014 01:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.249 X-Spam-Level: X-Spam-Status: No, score=0.249 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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.272, 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 uJknVKN-lit5 for ; Wed, 16 Apr 2014 01:44:44 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 3C1B51A00F4 for ; Wed, 16 Apr 2014 01:44:44 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id rl12so9733583iec.8 for ; Wed, 16 Apr 2014 01:44:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=K2kBr2IoX7DgT7QUDifY+HfDpfFG5Xx3XyKdbUMmT88=; b=F6jLodIgxVQSwH9BJtGFU9FjhVkulR7YKXAlaubn/ZZOs2iABe5OvwbPonAzaofN/h kdUmJNmYJQlFmI7LME8V1JQSfYBiNorYyLLy4BIJPCu8gu3caJRjJiFWmLD3TyqmFAYv bV2I1DleXfjRfL3QO2VYVt3DB9IXbzjjTly2wjA8APnTZjcoJRuC+VZsz4h9jD+1rtOl izFiOqqp/zF22JMAhK1ioD32qQWuQvkGVyJnfu8IjxqwGYBVVH4KyNfw1OTLdApN74cd hvLezX48n0crFjQYYPLx5W2gyxr4MCH3mAfZm9QBmMQTG4JgA/uQKkjinoosfXxPM7p8 iVjg== 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=K2kBr2IoX7DgT7QUDifY+HfDpfFG5Xx3XyKdbUMmT88=; b=YeAQ2WVrzPfnAO3vW37p1akHUcngI/dgJfdglzNhAbrMzPtLrsJsa3kbK7pFoPKAi7 nhxejtAqudLFNFh7h9172C7hZ4ErpnIE0EiS7bX8V5QYqvDcITnm//R35mvoc4NvAHsh 8NQyd3G9BVO+SXFokIRWkJfAVNVnfFn36A6SaiIF53MVb/gpwekR838/ky7w5E8Hc1kq Gs9p/b8HA8fEUuIuWs1mULpIH0A3VRPwBIsb3LpyAsL8RITiQlT7gBGQl2Op05hZvYls kxTS7sbIdyJfQHI3ca+tkU6rybSvjz2J62qfClwgFpImQvXtgaN+bh0frjzCwN2S6pTK B1tw== X-Gm-Message-State: ALoCoQlZYFBQ1IPs4QRGlxvl9FCQsyrwmd6cqKEMW0dQSRiDM4E1VqgBuzcn3BRxK04NIYmCsJO9nTfgOw8XL8JXuAdcdjhgz4o2TIAlQoPWDR44v+n3YTnoHcyZCPKXEg92b+8HAZt/zaBmx6UTQkW8WP2qQpEYJJfWF+MVnnAZjaX0XVncmvKHmWVH1LPvNTBJpj5Rth77 X-Received: by 10.42.226.8 with SMTP id iu8mr2913192icb.7.1397637880783; Wed, 16 Apr 2014 01:44:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.18.136 with HTTP; Wed, 16 Apr 2014 01:44:20 -0700 (PDT) In-Reply-To: References: <534BF803.3090600@viagenie.ca> <87wqes3pms.fsf@toke.dk> <534C214F.6010603@viagenie.ca> <878ur67rx2.fsf@toke.dk> <534D383E.2090602@viagenie.ca> <534D4F40.5050102@viagenie.ca> <534D58E7.2050702@viagenie.ca> From: Lorenzo Colitti Date: Wed, 16 Apr 2014 17:44:20 +0900 Message-ID: To: Ted Lemon Content-Type: multipart/alternative; boundary=001a11c30f9e68bd4e04f724ed20 Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/5rjBstkZJv-dK0uSHSXPfv1Pngo Cc: "homenet@ietf.org" , Philip Homburg Subject: Re: [homenet] Please review the No IPv4 draft 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, 16 Apr 2014 08:44:46 -0000 --001a11c30f9e68bd4e04f724ed20 Content-Type: text/plain; charset=UTF-8 On Wed, Apr 16, 2014 at 2:09 AM, Ted Lemon wrote: > I'm sorry, but I have no sympathy for your protestations about DHCPv4 > clients in embedded applications. If it's an RPi, you can run a > full-featured DHCPv4/DHCPv6 implementation that works, so there's no excuse > for running one that doesn't. > Ted, I think you'll have to accept that Philip's assessment of how much work has to be done on his platform is accurate, since he's the one writing that code. We've had this discussion many times on many different drafts, and every time the conclusions from the implementers (and of course, not from the standards writers) was that tying together the state machines from different protocol provisioning mechanisms was brittle and a lot of work. An excellent example is provided by the CPE RFCs, 6204/7084, which explicitly ignore the M and O bits and go out of their way to specify that the DHCPv6 state machine and RA processing parts of the code can be separate and run as ships in the night. That was based on extensive feedback from implementers, who pushed back hard against any sort of requirement to tie multple provisioning protocols together. You're free to say that the "many different provisioning daemons" model used by Linux and many CPEs is junk and that the multi-process model will be replaced by monolithic system configuration daemons, but bear in mind that that's not the current state of affairs in the real world. The IETF is always free to come to consensus on the option that's hard to implement. Unfortunately what typically happens after that is that it doesn't get implemented. --001a11c30f9e68bd4e04f724ed20 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Apr 16, 2014 at 2:09 AM, Ted Lemon <mellon@fugue.com> wro= te:
I'm sorry, but I have no sympathy for your protestation= s about DHCPv4 clients in embedded applications. =C2=A0 If it's an RPi,= you can run a full-featured DHCPv4/DHCPv6 implementation that works, so th= ere's no excuse for running one that doesn't.

Ted, I think you'll have to accept tha= t Philip's assessment of how much work has to be done on his platform i= s accurate, since he's the one writing that code.

We've had this discussion many times on many different drafts, and= every time the conclusions from the implementers (and of course, not from = the standards writers) was that tying together the state machines from diff= erent protocol provisioning mechanisms was brittle and a lot of work.

An excellent example is provided by the CPE RFCs,= 6204/7084, which explicitly ignore the M and O bits and go out of their wa= y to specify that the DHCPv6 state machine and RA processing parts of the c= ode can be separate and run as ships in the night. That was based on extens= ive feedback from implementers, who pushed back hard against any sort of re= quirement to tie multple provisioning protocols together.

You're free to say that the "many differe= nt provisioning daemons" model used by Linux and many CPEs is junk and= that the multi-process model will be replaced by monolithic system configu= ration daemons, but bear in mind that that's not the current state of a= ffairs in the real world.

The IETF is always free to come to consensus on t= he option that's hard to implement. Unfortunately what typically happen= s after that is that it doesn't get implemented.
--001a11c30f9e68bd4e04f724ed20-- From nobody Wed Apr 16 02:42: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 C75321A0040 for ; Wed, 16 Apr 2014 02:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.2 X-Spam-Level: X-Spam-Status: No, score=-6.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-2.3] 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 FyQuWbWLxyLL for ; Wed, 16 Apr 2014 02:42:07 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 420901A0013 for ; Wed, 16 Apr 2014 02:42:07 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #76) id m1WaLe6-0000AmC; Wed, 16 Apr 2014 10:56:42 +0200 Message-Id: To: Mark Andrews From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <534BF803.3090600@viagenie.ca> <87wqes3pms.fsf@toke.dk> <534C214F.6010603@viagenie.ca> <878ur67rx2.fsf@toke.dk> <534D383E.2090602@viagenie.ca> <534D4F40.5050102@viagenie.ca> <534D58E7.2050702@viagenie.ca> <9068E42F-3E85-4D2F-AB57-234365CFE1C7@fugue.com> <20140416002851.1FBA013CD524@rock.dv.isc.org> In-reply-to: Your message of "Wed, 16 Apr 2014 10:28:51 +1000 ." <20140416002851.1FBA013CD524@rock.dv.isc.org> Date: Wed, 16 Apr 2014 10:55:47 +0200 Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/JRbJ19AeIP8kNIjtMEmk20swo-A Cc: homenet@ietf.org, Ted Lemon Subject: Re: [homenet] Please review the No IPv4 draft 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, 16 Apr 2014 09:42:08 -0000 In your letter dated Wed, 16 Apr 2014 10:28:51 +1000 you wrote: >There is already userland code that reacts to RA flags in FreeBSD >to start dhcpv6. It's not hard to add yet another callback to >stop/start dhcpv4. I suspect if I sat down to do this I could do >code it in a day. This is not rocket science. I could do it from >scratch with raw sockets in just about as much time. I just need >to be able to see the RA's and know what interface they arrived on. Does that include all edge cases and the user interface? I.e. DHCPv4 has configured an address and by mistake a RA orders IPv4 to be shutdown. Do you just shutdown IPv4? Does your code parse the output of ifconfig to figure out if the interface was configured? The user doesn't want this to happen on a production IPv4 network. Where in the FreeBSD admin interface do you put the option to disable this behavior? An admin has stopped DHCPv4, now an RA comes along with the option to start IPv4. Does your code just start DHPv4 or does it know that an admin took it down? Just a few the came to mind. I'm sure that when this is taken into production there will be many more. And many confused admins who don't understand why DHCPv4 is suddenly starting or stopping. In contrast a DHCPNOSERVICE message that just suspends sending DHCPDISCOVER messages for a while has almost no impact. It gets slightly trickier if that also implies no link local, but not much. From nobody Wed Apr 16 03:14: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 EC1B61A0116 for ; Wed, 16 Apr 2014 03:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.173 X-Spam-Level: X-Spam-Status: No, score=-9.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, 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 Xunp9cQG-N_R for ; Wed, 16 Apr 2014 03:13:53 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) by ietfa.amsl.com (Postfix) with ESMTP id F3C3E1A0106 for ; Wed, 16 Apr 2014 03:13:52 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP id 4611B349410; Wed, 16 Apr 2014 10:13:49 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id DFC5C160059; Wed, 16 Apr 2014 10:15:57 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id ACD6516000E; Wed, 16 Apr 2014 10:15:57 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id B8C1213F1074; Wed, 16 Apr 2014 20:13:45 +1000 (EST) To: Philip Homburg From: Mark Andrews References: <534BF803.3090600@viagenie.ca> <87wqes3pms.fsf@toke.dk> <534C214F.6010603@viagenie.ca> <878ur67rx2.fsf@toke.dk> <534D383E.2090602@viagenie.ca> <534D4F40.5050102@viagenie.ca> <534D58E7.2050702@viagenie.ca> <9068E42F-3E85-4D2F-AB57-234365CFE1C7@fugue.com> <20140416002851.1FBA013CD524@rock.dv.isc.org> In-reply-to: Your message of "Wed, 16 Apr 2014 10:55:47 +0200." Date: Wed, 16 Apr 2014 20:13:45 +1000 Message-Id: <20140416101345.B8C1213F1074@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/2mUGuefFEORaWRbWvrU2JfgNOKw Cc: homenet@ietf.org, Ted Lemon Subject: Re: [homenet] Please review the No IPv4 draft 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, 16 Apr 2014 10:13:58 -0000 In message , Philip Homburg writes: > In your letter dated Wed, 16 Apr 2014 10:28:51 +1000 you wrote: > >There is already userland code that reacts to RA flags in FreeBSD > >to start dhcpv6. It's not hard to add yet another callback to > >stop/start dhcpv4. I suspect if I sat down to do this I could do > >code it in a day. This is not rocket science. I could do it from > >scratch with raw sockets in just about as much time. I just need > >to be able to see the RA's and know what interface they arrived on. > > Does that include all edge cases and the user interface? > > I.e. DHCPv4 has configured an address and by mistake a RA orders IPv4 to be > shutdown. Do you just shutdown IPv4? Does your code parse the output of > ifconfig to figure out if the interface was configured? Yes. Why not as it been told it is allowed to shutdown IPv4 in the interface? > The user doesn't want this to happen on a production IPv4 network. Where in > the FreeBSD admin interface do you put the option to disable this behavior? Given we are taking about FreeBSD /etc/rc.conf it would be ifconfig_ed0_ranoipv4="NO" in there with the default in /etc/defaults/rc.conf ifconfig_ed0_ranoipv4="YES" possibly commented out. > An admin has stopped DHCPv4, now an RA comes along with the option to start > IPv4. Does your code just start DHPv4 or does it know that an admin took it > down? More correctly it was told to start IPv4 and yes. The admin should have temporarially disabled processing of the option if he didn't want ipv4 restarted. It is not uncommon for functions to auto start. If I fiddle with /etc/resolv.conf DHCP will re-write it on the next renew. This is similar. > Just a few the came to mind. I'm sure that when this is taken into production > there will be many more. And many confused admins who don't understand why > DHCPv4 is suddenly starting or stopping. Only because it is new. Once it is known about there won't be much confusion. > In contrast a DHCPNOSERVICE message that just suspends sending DHCPDISCOVER > messages for a while has almost no impact. It gets slightly trickier if > that also implies no link local, but not much. And doesn't achieve the intent of turning off IPv4 for the interface when you are not configuring using DHCP. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Wed Apr 16 05:52:26 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 E27DF1A015F for ; Wed, 16 Apr 2014 05:52:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.773 X-Spam-Level: X-Spam-Status: No, score=-0.773 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.272, 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 83fxSDFWCrZN for ; Wed, 16 Apr 2014 05:52:17 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB811A0167 for ; Wed, 16 Apr 2014 05:49:16 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:2520:ef8a:477:622f]) by jazz.viagenie.ca (Postfix) with ESMTPSA id D210B40063 for ; Wed, 16 Apr 2014 08:49:12 -0400 (EDT) Message-ID: <534E7C48.6070001@viagenie.ca> Date: Wed, 16 Apr 2014 08:49:12 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: homenet@ietf.org References: <534BF803.3090600@viagenie.ca> <87wqes3pms.fsf@toke.dk> <534C214F.6010603@viagenie.ca> <878ur67rx2.fsf@toke.dk> <534D383E.2090602@viagenie.ca> <534D4F40.5050102@viagenie.ca> <534D58E7.2050702@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/rrBlAtvmx4vtpFAxogkj94ZfvxY Subject: Re: [homenet] Please review the No IPv4 draft 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, 16 Apr 2014 12:52:23 -0000 Le 2014-04-16 04:44, Lorenzo Colitti a écrit : > I'm sorry, but I have no sympathy for your protestations about > DHCPv4 clients in embedded applications. If it's an RPi, you can > run a full-featured DHCPv4/DHCPv6 implementation that works, so > there's no excuse for running one that doesn't. > > > Ted, I think you'll have to accept that Philip's assessment of how much > work has to be done on his platform is accurate, since he's the one > writing that code. On his platform, sure. On all the platforms I know, it would be trivial. > We've had this discussion many times on many different drafts, and every > time the conclusions from the implementers (and of course, not from the > standards writers) was that tying together the state machines from > different protocol provisioning mechanisms was brittle and a lot of work. They are already tied together on many platforms. NetworkManager, systemd, Android, Mac, Windows, etc. /etc/rc.d/dhclient is dead. And that's a good thing. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Wed Apr 16 06:08: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 477D01A015F for ; Wed, 16 Apr 2014 06:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.163 X-Spam-Level: X-Spam-Status: No, score=-2.163 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=0.01] 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 vULuqA_0Iasz for ; Wed, 16 Apr 2014 06:07:53 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.252.184]) by ietfa.amsl.com (Postfix) with ESMTP id D88EE1A0127 for ; Wed, 16 Apr 2014 06:07:52 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 2CAC22003A for ; Wed, 16 Apr 2014 09:08:10 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 9050D63ABF; Wed, 16 Apr 2014 09:07:46 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 798BD63AA2 for ; Wed, 16 Apr 2014 09:07:46 -0400 (EDT) From: Michael Richardson To: homenet@ietf.org In-Reply-To: References: <534BF803.3090600@viagenie.ca> <87wqes3pms.fsf@toke.dk> <534C214F.6010603@viagenie.ca> <878ur67rx2.fsf@toke.dk> <534D383E.2090602@viagenie.ca> <534D4F40.5050102@viagenie.ca> <534D58E7.2050702@viagenie.ca> <9068E42F-3E85-4D2F-AB57-234365CFE1C7@fugue.com> <20140416002851.1FBA013CD524@rock.dv.isc.org> 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 Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/ptmgvsrmpW3ysLIFJzgnmKx96xY Subject: Re: [homenet] Please review the No IPv4 draft 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, 16 Apr 2014 13:07:57 -0000 --=-=-= {I would love a description from Apple and Microsoft of how their layer-2/layer-3 address discovery/configurartion systems already interact} Philip Homburg wrote: > Does that include all edge cases and the user interface? > I.e. DHCPv4 has configured an address and by mistake a RA orders IPv4 > to be > shutdown. Do you just shutdown IPv4? Does your code parse the output of > ifconfig to figure out if the interface was configured? No, and no. The order is not to shutdown v4. The suggestion is to stop DHCPv4, if it hasn't succeeded, and assume that there isn't any IPv4 for any downstream devices. Ideally the device will not announce an IPv4 default route if it hasn't got one itself. If the admin has manually configured IPv4, then there is no issue. What the ISP wants to prevent is barages of DHCPv4 broadcasts, and what the homenet situation wants is to avoid offering an IPv4 default route when it won't work. > In contrast a DHCPNOSERVICE message that just suspends sending > DHCPDISCOVER messages for a while has almost no impact. It gets > slightly trickier if > that also implies no link local, but not much. It's not that there isn't v4, it's that there isn't DHCPv4. I personally think that both should actually exist. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBU06AooqHRg3pndX9AQINOQP/VRDO9bg6WYo3GZfPFe8kcrpMQ/pgn5rx R3iPe0+1P/KlFFr2QSlizUjMCyn4Kuo+vweRd7G+FTgrj/+xI988uxuNZ41hjNxt IUuyj7e+2jBfqPgTGSY36lGGWZ+VZA36GDa4pihqz0Htybq15A3kTC5ereGvJ7Ke ODvLKf35i5k= =jnPY -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Apr 16 06:38: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 E27931A019B for ; Wed, 16 Apr 2014 06:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2] 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 v9yV_-2fvdEx for ; Wed, 16 Apr 2014 06:37:56 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id BDD0F1A019C for ; Wed, 16 Apr 2014 06:37:55 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #76) id m1WaQ2B-0000BmC; Wed, 16 Apr 2014 15:37:51 +0200 Message-Id: To: homenet@ietf.org From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <534BF803.3090600@viagenie.ca> <87wqes3pms.fsf@toke.dk> <534C214F.6010603@viagenie.ca> <878ur67rx2.fsf@toke.dk> <534D383E.2090602@viagenie.ca> <534D4F40.5050102@viagenie.ca> <534D58E7.2050702@viagenie.ca> <9068E42F-3E85-4D2F-AB57-234365CFE1C7@fugue.com> <20140416002851.1FBA013CD524@rock.dv.isc.org> <20492.1397653666@sandelman.ca> In-reply-to: Your message of "Wed, 16 Apr 2014 09:07:46 -0400 ." <20492.1397653666@sandelman.ca> Date: Wed, 16 Apr 2014 15:37:45 +0200 Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/r9AeFJpxc7iKHWusvO7HetPpReA Cc: Michael Richardson Subject: Re: [homenet] Please review the No IPv4 draft 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, 16 Apr 2014 13:38:02 -0000 In your letter dated Wed, 16 Apr 2014 09:07:46 -0400 you wrote: >Philip Homburg wrote: > > Does that include all edge cases and the user interface? > > > I.e. DHCPv4 has configured an address and by mistake a RA orders IPv4 > > to be > > shutdown. Do you just shutdown IPv4? Does your code parse the output of > > ifconfig to figure out if the interface was configured? > >No, and no. > >The order is not to shutdown v4. The suggestion is to stop DHCPv4, if it >hasn't succeeded, and assume that there isn't any IPv4 for any downstream >devices. (This was in the context of FreeBSD.) One option: the DHCPv4 client has an option to shutdown unless it already obtained a lease. Probably requires allocating a signal, changes to the DHCPv4 client, etc. Otherwise, what happens if you kill a DHCPv4 client when it has a lease? - A hard kill (-9) and the address remains installed even when the lease expires. Not good. - (Unlikely) A hard kill and the kernel knows about the lifetime of the lease and deletes the address when it expires. This one would be really great to debug. Send one 'ipv4begone' packet and hour later the admin goes crazy. - A soft kill (say TERM) and DHCPv4 removes the address before shutting down. Nice immediate DoS on IPv4. Alternative, ifconfig $interface | grep 'inet '... Ugly. And unless all of this is spelled out in the RFC in extreme detail, I can already see the presentations in a couple of years: we sent one 'ipv4begone' packet and this is the kind of fireworks you get in the various operating systems. Somebody might just go ahead and implement 'grep "option no-ipv4" /var/db/dhclient6.leases.eth0 && pkill dhclient' ... From nobody Wed Apr 16 06:40: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 1D13E1A019B for ; Wed, 16 Apr 2014 06:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 NhuSBxQ0z5Mu for ; Wed, 16 Apr 2014 06:40:56 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9E8651A0193 for ; Wed, 16 Apr 2014 06:40:56 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:2520:ef8a:477:622f]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 5042B403BC for ; Wed, 16 Apr 2014 09:40:53 -0400 (EDT) Message-ID: <534E8865.1010609@viagenie.ca> Date: Wed, 16 Apr 2014 09:40:53 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: homenet@ietf.org References: <534BF803.3090600@viagenie.ca> <87wqes3pms.fsf@toke.dk> <534C214F.6010603@viagenie.ca> <878ur67rx2.fsf@toke.dk> <534D383E.2090602@viagenie.ca> <534D4F40.5050102@viagenie.ca> <534D58E7.2050702@viagenie.ca> <9068E42F-3E85-4D2F-AB57-234365CFE1C7@fugue.com> <20140416002851.1FBA013CD524@rock.dv.isc.org> <20492.1397653666@sandelman.ca> In-Reply-To: <20492.1397653666@sandelman.ca> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/KpgWkFrSe-GfqKoxAZK-Vg1KKco Subject: Re: [homenet] Please review the No IPv4 draft 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, 16 Apr 2014 13:40:58 -0000 Le 2014-04-16 09:07, Michael Richardson a écrit : > Ideally the device will not announce an IPv4 default route if it hasn't got > one itself. The fact is that all CPE routers today do announce an IPv4 default route to the LAN irrespective of their WAN connectivity status. And there's no reason to think that this will ever change. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Wed Apr 16 07:52:42 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 80E171A015D for ; Wed, 16 Apr 2014 07:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 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.272, 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 dQ4QtSGLU7d0 for ; Wed, 16 Apr 2014 07:52:36 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 911BB1A01F0 for ; Wed, 16 Apr 2014 07:52:36 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id lx4so10686260iec.9 for ; Wed, 16 Apr 2014 07:52:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=70mMWIlx+DobicyofcXCQ3N4mSGqZQli04OV/izOQ9k=; b=IbqDwKBm6jaEb+1aWlTzv+UoMDA/Mb4EoJdS1qoR+MRxIvVk1tN1nkFQ46llS3kUCX LzymQkbqsxIXYZ0nBWAKaHMQEgsGkS3WUJvgqormL/yp7sXgpJK3n1sUHypS+eww4Phd DqjCkewZGGzBDTh9p4u6h7922pE/1nzjMvWQap4NjaEJpqcm13kVjsDexAEVEqJ6sM5F a+2AsF5gHYzVqAxMpqu3TjoPD+dd/tM2B4D7RmrKGC+t/gralc+FcQCgejNGnOLsrkix be6ZT7dp3x0br5kOlZoYVZ4k7Tg06eO2nhTkW4yl4KXzZVsGBhkkO7fKXkv7JLKa1xTd 4zMw== 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=70mMWIlx+DobicyofcXCQ3N4mSGqZQli04OV/izOQ9k=; b=lZLzpDlMGmuw8JoGE5dtBzrmw57rhJt8Xi77PUSsea3KTI8y2MpBT5y1TJ6IVsrPui JzW6FBLw7cOVF/nxijKlXfKZVAlEZYF60K7NbNM30+cDtO5Yxy2up2z4RqiiUQvXLFcr avFLn1xkrdsoFsSzByEOQ7T1FKPrBrlHH2sGQpR7XRWqXkOpKCDou14lGAd7QMoBpo8y +3aYtS7un9mfE1/s0SODh4PHnAEzjpK+UXRofGPUGAsatonlKRr4UY3zwxavg+kDGjrQ SLsRx+TzkIyYv1+ZiQhoG+CcH+jkM4BogeVqpXDvwV98tgxjkQdZQwxMuozcdIF0Ipha cajQ== X-Gm-Message-State: ALoCoQmP95BrPpMlS3wL8TgNc09A3lNuooPlAa5IZx+Hr6XcHQ3G0B+D8XkLSzK659Kspe8mZdpwbmbw1+gNKlyfZFBIYA0WtrtEQjANe8Y4/hUdt4R4Z6cHOJA8CeQxDzhUTWRrB9LQhSg2LDty6w2An3fIxyA843Rcpu4tC9Mj3gnS0UlO13279ZbEyAJVzSMT04L1dPBG X-Received: by 10.42.20.6 with SMTP id e6mr4296517icb.29.1397659953120; Wed, 16 Apr 2014 07:52:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.18.136 with HTTP; Wed, 16 Apr 2014 07:52:13 -0700 (PDT) In-Reply-To: <534E7C48.6070001@viagenie.ca> References: <534BF803.3090600@viagenie.ca> <87wqes3pms.fsf@toke.dk> <534C214F.6010603@viagenie.ca> <878ur67rx2.fsf@toke.dk> <534D383E.2090602@viagenie.ca> <534D4F40.5050102@viagenie.ca> <534D58E7.2050702@viagenie.ca> <534E7C48.6070001@viagenie.ca> From: Lorenzo Colitti Date: Wed, 16 Apr 2014 23:52:13 +0900 Message-ID: To: Simon Perreault Content-Type: multipart/alternative; boundary=f46d04190e6205ec5d04f72a1111 Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/7vNYRh8Da3QrH-2WrF3WGpSCXnY Cc: "homenet@ietf.org" Subject: Re: [homenet] Please review the No IPv4 draft 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, 16 Apr 2014 14:52:39 -0000 --f46d04190e6205ec5d04f72a1111 Content-Type: text/plain; charset=UTF-8 On Wed, Apr 16, 2014 at 9:49 PM, Simon Perreault < simon.perreault@viagenie.ca> wrote: > They are already tied together on many platforms. NetworkManager, > systemd, Android, Mac, Windows, etc. /etc/rc.d/dhclient is dead. And > that's a good thing. Not Android. --f46d04190e6205ec5d04f72a1111 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Apr 16, 2014 at 9:49 PM, Simon Perreault <simon.perreault@v= iagenie.ca> wrote:
They are already tied together on many platf= orms. NetworkManager,
systemd, Android, Mac, Windows, etc. /etc/rc.d/dhclient is dead. And
that's a good thing.

Not Android.=C2=A0=
--f46d04190e6205ec5d04f72a1111-- From nobody Wed Apr 16 07:54: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 CCCA01A0215 for ; Wed, 16 Apr 2014 07:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 QTlIvTaRnrXi for ; Wed, 16 Apr 2014 07:54:18 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 4A6841A0214 for ; Wed, 16 Apr 2014 07:54:18 -0700 (PDT) Received: from [192.168.43.134] ([172.56.38.54]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s3GEsD2J077310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 16 Apr 2014 14:54:14 GMT (envelope-from joelja@bogus.com) Message-ID: <534E998E.2060704@bogus.com> Date: Wed, 16 Apr 2014 07:54:06 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:28.0) Gecko/20100101 Thunderbird/28.0 MIME-Version: 1.0 To: Simon Perreault , homenet@ietf.org References: <534BF803.3090600@viagenie.ca> <87wqes3pms.fsf@toke.dk> <534C214F.6010603@viagenie.ca> <878ur67rx2.fsf@toke.dk> <534D383E.2090602@viagenie.ca> <534D4F40.5050102@viagenie.ca> <534D58E7.2050702@viagenie.ca> <9068E42F-3E85-4D2F-AB57-234365CFE1C7@fugue.com> <20140416002851.1FBA013CD524@rock.dv.isc.org> <20492.1397653666@sandelman.ca> <534E8865.1010609@viagenie.ca> In-Reply-To: <534E8865.1010609@viagenie.ca> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ie3lg5jPmV3Et7Hs5B7eRmuBda5XgXsCx" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Wed, 16 Apr 2014 14:54:15 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/MG5bpROCzM-OYMB9LNkjxBP-iRo Subject: Re: [homenet] Please review the No IPv4 draft 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, 16 Apr 2014 14:54:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ie3lg5jPmV3Et7Hs5B7eRmuBda5XgXsCx Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 4/16/14, 6:40 AM, Simon Perreault wrote: > Le 2014-04-16 09:07, Michael Richardson a =E9crit : >> Ideally the device will not announce an IPv4 default route if it hasn'= t got >> one itself. >=20 > The fact is that all CPE routers today do announce an IPv4 default rout= e > to the LAN irrespective of their WAN connectivity status. And there's n= o > reason to think that this will ever change. ipv4 cpe using rfc 1497/2132 option 3 are not announcing a default route, they are indicating that they are a router, the client installs the default route. > Simon >=20 --ie3lg5jPmV3Et7Hs5B7eRmuBda5XgXsCx 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/ iEYEARECAAYFAlNOmY4ACgkQ8AA1q7Z/VrLnTwCgiW1DYk8R8jYwaaFr8TxSPnbr WKIAn2rjnLdySJK09j7vjbs2w9JZJZ/f =2fbl -----END PGP SIGNATURE----- --ie3lg5jPmV3Et7Hs5B7eRmuBda5XgXsCx-- From nobody Wed Apr 16 08:03: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 6EA9E1A01D8 for ; Wed, 16 Apr 2014 08:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 gfRBMjuR8ZTG for ; Wed, 16 Apr 2014 08:03:09 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id ABD011A01B1 for ; Wed, 16 Apr 2014 08:03:09 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:2520:ef8a:477:622f]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 3EC1C403DC; Wed, 16 Apr 2014 11:03:06 -0400 (EDT) Message-ID: <534E9BA9.1010408@viagenie.ca> Date: Wed, 16 Apr 2014 11:03:05 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Lorenzo Colitti References: <534BF803.3090600@viagenie.ca> <87wqes3pms.fsf@toke.dk> <534C214F.6010603@viagenie.ca> <878ur67rx2.fsf@toke.dk> <534D383E.2090602@viagenie.ca> <534D4F40.5050102@viagenie.ca> <534D58E7.2050702@viagenie.ca> <534E7C48.6070001@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/mHSKCUENaFyNTznXOdIDH1MKGdM Cc: "homenet@ietf.org" Subject: Re: [homenet] Please review the No IPv4 draft 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, 16 Apr 2014 15:03:12 -0000 Le 2014-04-16 10:52, Lorenzo Colitti a Ă©crit : > On Wed, Apr 16, 2014 at 9:49 PM, Simon Perreault > > wrote: > > They are already tied together on many platforms. NetworkManager, > systemd, Android, Mac, Windows, etc. /etc/rc.d/dhclient is dead. And > that's a good thing. > > > Not Android. You're right, my mistake. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Wed Apr 16 08:05:26 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 DC9BD1A01B1 for ; Wed, 16 Apr 2014 08:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 gG86enHndSiA for ; Wed, 16 Apr 2014 08:05:00 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 039E61A01B0 for ; Wed, 16 Apr 2014 08:04:40 -0700 (PDT) Received: from [192.168.146.119] (unknown [70.114.139.95]) by toccata.fugue.com (Postfix) with ESMTPSA id 2EE65238038A; Wed, 16 Apr 2014 11:04:35 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: Date: Wed, 16 Apr 2014 10:04:35 -0500 Content-Transfer-Encoding: 7bit Message-Id: <4C9B747D-451A-456F-BF59-E447583A04E6@fugue.com> References: <534BF803.3090600@viagenie.ca> <87wqes3pms.fsf@toke.dk> <534C214F.6010603@viagenie.ca> <878ur67rx2.fsf@toke.dk> <534D383E.2090602@viagenie.ca> <534D4F40.5050102@viagenie.ca> <534D58E7.2050702@viagenie.ca> <534E7C48.6070001@viagenie.ca> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/xxU0Dv_bWRl-A2SUUBJNINbvy0E Cc: "homenet@ietf.org" Subject: Re: [homenet] Please review the No IPv4 draft 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, 16 Apr 2014 15:05:09 -0000 On Apr 16, 2014, at 9:52 AM, Lorenzo Colitti wrote: > Not Android. I thought Android used dnsmasq. From nobody Wed Apr 16 09:25: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 AC65F1A0249 for ; Wed, 16 Apr 2014 09:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 U72zCXa3yNqa for ; Wed, 16 Apr 2014 09:25:18 -0700 (PDT) Received: from bytemark.thekelleys.org.uk (bytemark.thekelleys.org.uk [IPv6:2001:41c8:51:46b:feff:ff:fe00:3310]) by ietfa.amsl.com (Postfix) with ESMTP id 5486F1A0248 for ; Wed, 16 Apr 2014 09:25:18 -0700 (PDT) Received: from [31.100.201.5] (helo=[192.168.150.151]) by bytemark.thekelleys.org.uk with esmtpa (Exim 4.80) (envelope-from ) id 1WaSe9-00008U-61 for homenet@ietf.org; Wed, 16 Apr 2014 16:25:13 +0000 Message-ID: <534EAEE6.1060305@thekelleys.org.uk> Date: Wed, 16 Apr 2014 17:25:10 +0100 From: Simon Kelley User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: homenet@ietf.org References: <534BF803.3090600@viagenie.ca> <87wqes3pms.fsf@toke.dk> <534C214F.6010603@viagenie.ca> <878ur67rx2.fsf@toke.dk> <534D383E.2090602@viagenie.ca> <534D4F40.5050102@viagenie.ca> <534D58E7.2050702@viagenie.ca> <534E7C48.6070001@viagenie.ca> <4C9B747D-451A-456F-BF59-E447583A04E6@fugue.com> In-Reply-To: <4C9B747D-451A-456F-BF59-E447583A04E6@fugue.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/YIyX6OGhdKOjBj5I_FiHMtYAUuQ Subject: Re: [homenet] Please review the No IPv4 draft 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, 16 Apr 2014 16:25:20 -0000 On 16/04/14 16:04, Ted Lemon wrote: > On Apr 16, 2014, at 9:52 AM, Lorenzo Colitti wrote: >> Not Android. > > I thought Android used dnsmasq. > Android uses dhcpcd as its DHCP client. Dnsmasq is used as DHCP and DNS _server_ for wireless and USB tethering. It has nothing to do with the Android DHCP client behaviour. Simon. > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > From nobody Wed Apr 16 11:32: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 3A8EF1A02AF for ; Wed, 16 Apr 2014 11:31:59 -0700 (PDT) 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 QJE-gka6ubwV for ; Wed, 16 Apr 2014 11:31:57 -0700 (PDT) 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 8AC0A1A02AE for ; Wed, 16 Apr 2014 11:31:57 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/46573) with ESMTP id s3GIVrdK025794; Wed, 16 Apr 2014 20:31:53 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 5A57C13620; Wed, 16 Apr 2014 20:31:53 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id zf5-fjE-IekF; Wed, 16 Apr 2014 20:31:38 +0200 (CEST) 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 10C0013618; Wed, 16 Apr 2014 20:31:37 +0200 (CEST) Date: Wed, 16 Apr 2014 20:31:44 +0200 Message-ID: <878ur5cei7.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Michael Richardson In-Reply-To: <28578.1397616059@sandelman.ca> References: <534BF803.3090600@viagenie.ca> <87wqes3pms.fsf@toke.dk> <534C214F.6010603@viagenie.ca> <878ur67rx2.fsf@toke.dk> <534D383E.2090602@viagenie.ca> <534D4F40.5050102@viagenie.ca> <534D58E7.2050702@viagenie.ca> <9068E42F-3E85-4D2F-AB57-234365CFE1C7@fugue.com> <4631.1397609719@sandelman.ca> <8761maozqq.wl%jch@pps.univ-paris-diderot.fr> <28578.1397616059@sandelman.ca> 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]); Wed, 16 Apr 2014 20:31:53 +0200 (CEST) X-Miltered: at korolev with ID 534ECC99.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 534ECC99.002 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 : 534ECC99.002 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/xfl1EWOsULPt5EnAaGGKZ-dvnAs Cc: homenet@ietf.org Subject: Re: [homenet] Please review the No IPv4 draft 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, 16 Apr 2014 18:31:59 -0000 >>> slowly I've gotten to understand the numerous layer-2 and layer-3 >>> savings by not having to have the whole DHCPv4 relay and broadcast >>> processing occuring. >> Could you please explain that? > let me see what I recall... That's interesting, especially the FTTH case. Thanks for the info. -- Juliusz From nobody Wed Apr 16 11:56: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 AF9371A0291 for ; Wed, 16 Apr 2014 11:56:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 8oLviHQIEx_n for ; Wed, 16 Apr 2014 11:56:22 -0700 (PDT) Received: from bytemark.thekelleys.org.uk (bytemark.thekelleys.org.uk [IPv6:2001:41c8:51:46b:feff:ff:fe00:3310]) by ietfa.amsl.com (Postfix) with ESMTP id 232011A020A for ; Wed, 16 Apr 2014 11:56:20 -0700 (PDT) Received: from [31.100.201.5] (helo=[192.168.150.151]) by bytemark.thekelleys.org.uk with esmtpa (Exim 4.80) (envelope-from ) id 1WaV0I-0000T4-An for homenet@ietf.org; Wed, 16 Apr 2014 18:56:14 +0000 Message-ID: <534ED24E.1070204@thekelleys.org.uk> Date: Wed, 16 Apr 2014 19:56:14 +0100 From: Simon Kelley User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: homenet@ietf.org References: <534BF803.3090600@viagenie.ca> <87wqes3pms.fsf@toke.dk> <534C214F.6010603@viagenie.ca> <878ur67rx2.fsf@toke.dk> <534D383E.2090602@viagenie.ca> <534D4F40.5050102@viagenie.ca> <534D58E7.2050702@viagenie.ca> <9068E42F-3E85-4D2F-AB57-234365CFE1C7@fugue.com> <4631.1397609719@sandelman.ca> <8761maozqq.wl%jch@pps.univ-paris-diderot.fr> <28578.1397616059@sandelman.ca> <878ur5cei7.wl%jch@pps.univ-paris-diderot.fr> In-Reply-To: <878ur5cei7.wl%jch@pps.univ-paris-diderot.fr> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/f2DScKZfr3aFyvLPFb0Y3OnRQ4M Subject: Re: [homenet] Please review the No IPv4 draft 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, 16 Apr 2014 18:56:23 -0000 I've not had time to review the whole thread, so apologies if this has been covered elsewhere. It occurs to me that one scenario that needs to considered is when a machine moves from a network which wants to suppress IPv4 to one which is still providing IPv4 (possibly only IPV4). To make that work implies that the DHCPv4 client should still exist in the IPv4-suppressed state, doing nothing except looking for loss of ethernet carrier or change of wireless ESSID, at which time is should try again to get a DHCPv4 lease. However this is implemented, just killing the DHCP client is not going to cut it. My personal feeling is that suppressing IPv4 should be a a DHCPv4 function, that keeps the go-into-hibernation transition solely in the DHCPv4 code, it also means the when IPv4 support finally goes, so does the transition mechanism. Simon. From nobody Wed Apr 16 13:17: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 128EF1A02A7 for ; Wed, 16 Apr 2014 13:17:53 -0700 (PDT) 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 KXbkLzpfSoFL for ; Wed, 16 Apr 2014 13:17:52 -0700 (PDT) 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 2D9191A0178 for ; Wed, 16 Apr 2014 13:17:51 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/46573) with ESMTP id s3GKHhVG017784; Wed, 16 Apr 2014 22:17:43 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 2701E1362A; Wed, 16 Apr 2014 22:17:43 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id GwQs5RFsVWRS; Wed, 16 Apr 2014 22:17:27 +0200 (CEST) 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 8D18013629; Wed, 16 Apr 2014 22:17:24 +0200 (CEST) Date: Wed, 16 Apr 2014 22:17:30 +0200 Message-ID: <871twxc9lx.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Ted Lemon In-Reply-To: References: <534BF803.3090600@viagenie.ca> <87wqes3pms.fsf@toke.dk> <534C214F.6010603@viagenie.ca> <878ur67rx2.fsf@toke.dk> <534D383E.2090602@viagenie.ca> <534D4F40.5050102@viagenie.ca> <534D58E7.2050702@viagenie.ca> <9068E42F-3E85-4D2F-AB57-234365CFE1C7@fugue.com> <87fvlep2pn.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]); Wed, 16 Apr 2014 22:17:43 +0200 (CEST) X-Miltered: at korolev with ID 534EE567.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 534EE567.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 : 534EE567.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/lnxHtRv_JWJxlrcGvs4DPvoDB3E Cc: homenet@ietf.org Subject: Re: [homenet] Please review the No IPv4 draft 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, 16 Apr 2014 20:17:53 -0000 > A technical objection is "this won't work because FOO." `I meant "there's a nice knock-down argument for you!"' `But "glory" doesn't mean "a nice knock-down argument,"' Alice objected. `When I use a word,' Humpty Dumpty said in rather a scornful tone, `it means just what I choose it to mean -- neither more nor less.' `The question is,' said Alice, `whether you can make words mean so many different things.' `The question is,' said Humpty Dumpty, `which is to be master -- that's all.' -- Juliusz From nobody Wed Apr 16 15: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 7A1191A03C3 for ; Wed, 16 Apr 2014 15:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 mnguvGCGPd57 for ; Wed, 16 Apr 2014 15:13:00 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1D71A02B7 for ; Wed, 16 Apr 2014 15:13:00 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id 8087E23839C; Wed, 16 Apr 2014 22:12:44 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id BF2EA160059; Wed, 16 Apr 2014 22:14:54 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 5C04B16000E; Wed, 16 Apr 2014 22:14:54 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 1958E13F33B1; Thu, 17 Apr 2014 08:12:41 +1000 (EST) To: Michael Richardson From: Mark Andrews References: <534BF803.3090600@viagenie.ca> <87wqes3pms.fsf@toke.dk> <534C214F.6010603@viagenie.ca> <878ur67rx2.fsf@toke.dk> <534D383E.2090602@viagenie.ca> <534D4F40.5050102@viagenie.ca> <534D58E7.2050702@viagenie.ca> <9068E42F-3E85-4D2F-AB57-234365CFE1C7@fugue.com> <20140416002851.1FBA013CD524@rock.dv.isc.org> <20492.1397653666@sandelman.ca> In-reply-to: Your message of "Wed, 16 Apr 2014 09:07:46 -0400." <20492.1397653666@sandelman.ca> Date: Thu, 17 Apr 2014 08:12:41 +1000 Message-Id: <20140416221241.1958E13F33B1@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/7jw1AiN8kKbGU7vwkTIQ4-jEzCk Cc: homenet@ietf.org Subject: Re: [homenet] Please review the No IPv4 draft 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, 16 Apr 2014 22:13:05 -0000 In message <20492.1397653666@sandelman.ca>, Michael Richardson writes: > > {I would love a description from Apple and Microsoft of how their > layer-2/layer-3 address discovery/configurartion systems already interact} > > Philip Homburg wrote: > > Does that include all edge cases and the user interface? > > > I.e. DHCPv4 has configured an address and by mistake a RA orders IPv4 > > to be > > shutdown. Do you just shutdown IPv4? Does your code parse the output of > > ifconfig to figure out if the interface was configured? > > No, and no. > > The order is not to shutdown v4. The suggestion is to stop DHCPv4, if it > hasn't succeeded, and assume that there isn't any IPv4 for any downstream > devices. With the currently defined states yes you shut down everything for 1 and 3. You don't shutdown for 0 and 2. I think some here want a currently undefined state, no dhcp but local connectivity. I would switch 1 and 2 around so that you go from most (0) to least (3) IPv4 support on the interface. Currently it is: 0 full IPv4 connectivity 1 all IPv4 off on the interface 2 local (link/site not global) connectivity only on the interface 3 no IPv4 on the machine. For 1 and 3 you remove all addressing on the interface in question. For 2 you leave DHCP running. It would be wise to not have default routes being announced by the DHCP server. Link-local may be in use if there isn't a DHCP server. I suspect that we may want a 5th state. No DHCP, local connectivity. That is split 2 into with and without DHCP. > Ideally the device will not announce an IPv4 default route if it hasn't got > one itself. If the admin has manually configured IPv4, then there is no issue > . > What the ISP wants to prevent is barages of DHCPv4 broadcasts, and what the > homenet situation wants is to avoid offering an IPv4 default route when it > won't work. > > > In contrast a DHCPNOSERVICE message that just suspends sending > > DHCPDISCOVER messages for a while has almost no impact. It gets > > slightly trickier if > > that also implies no link local, but not much. > > It's not that there isn't v4, it's that there isn't DHCPv4. > I personally think that both should actually exist. > > -- > ] Never tell me the odds! | ipv6 mesh networks > [ > ] Michael Richardson, Sandelman Software Works | network architect > [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails > [ > > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > --=-=-= > Content-Type: application/pgp-signature > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > > iQCVAwUBU06AooqHRg3pndX9AQINOQP/VRDO9bg6WYo3GZfPFe8kcrpMQ/pgn5rx > R3iPe0+1P/KlFFr2QSlizUjMCyn4Kuo+vweRd7G+FTgrj/+xI988uxuNZ41hjNxt > IUuyj7e+2jBfqPgTGSY36lGGWZ+VZA36GDa4pihqz0Htybq15A3kTC5ereGvJ7Ke > ODvLKf35i5k= > =jnPY > -----END PGP SIGNATURE----- > --=-=-=-- > > > --===============1429064588242792841== > Content-Type: text/plain; charset="us-ascii" > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > > --===============1429064588242792841==-- > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Wed Apr 16 18:02: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 C4A651A007D for ; Wed, 16 Apr 2014 18:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.163 X-Spam-Level: X-Spam-Status: No, score=-2.163 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=0.01] 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 kiIbA0ndvDlQ for ; Wed, 16 Apr 2014 18:02:34 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.252.184]) by ietfa.amsl.com (Postfix) with ESMTP id 7F3801A004D for ; Wed, 16 Apr 2014 18:02:34 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 0E24920031; Wed, 16 Apr 2014 21:02:52 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id AF57463ABD; Wed, 16 Apr 2014 21:02:27 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 9F9BD63ABA; Wed, 16 Apr 2014 21:02:27 -0400 (EDT) From: Michael Richardson To: homenet@ietf.org In-Reply-To: <20140416221241.1958E13F33B1@rock.dv.isc.org> References: <534BF803.3090600@viagenie.ca> <87wqes3pms.fsf@toke.dk> <534C214F.6010603@viagenie.ca> <878ur67rx2.fsf@toke.dk> <534D383E.2090602@viagenie.ca> <534D4F40.5050102@viagenie.ca> <534D58E7.2050702@viagenie.ca> <9068E42F-3E85-4D2F-AB57-234365CFE1C7@fugue.com> <20140416002851.1FBA013CD524@rock.dv.isc.org> <20492.1397653666@sandelman.ca> <20140416221241.1958E13F33B1@rock.dv.isc.org> 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 Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/Ty_e-AOKbXdSgkvlXaCtxeOQgJw Cc: Mark Andrews Subject: Re: [homenet] Please review the No IPv4 draft 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, 17 Apr 2014 01:02:39 -0000 --=-=-= Mark Andrews wrote: > With the currently defined states yes you shut down everything for 1 and > 3. You don't shutdown for 0 and 2. I think some here want a currently > undefined state, no dhcp but local connectivity. > I would switch 1 and 2 around so that you go from most (0) to least (3) > IPv4 support on the interface. I agree. > Currently it is: > 0 full IPv4 connectivity > 1 all IPv4 off on the interface > 2 local (link/site not global) connectivity only on the interface > 3 no IPv4 on the machine. > For 1 and 3 you remove all addressing on the interface in question. It's just that no DHCP (v4 or v6) server has really any clue about what should happen on the *machine*. It might have many other interfaces. There might also be other DHCP* servers on that interface, and some of them might not be spoofed! -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBU08oI4qHRg3pndX9AQKd3AP/aCrUrV7WIuCufPydKRQbzHTjT6z7qWz/ VIbVtEgeocRJ6fMfsNXAMR0BrZmOmtQbTPDjuDLu5zJO1geQysz8c2KvAW6k/HMW sKrrsZhbLpKFoX3HzHvtCbfsSTVK7otHdiDknV2SWrT63uhrrSBwfUjyJ+aIL5Cj OZ7FkiAYUHk= =MoPi -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Apr 16 18:31:32 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 F3D871A039D for ; Wed, 16 Apr 2014 18:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 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.272, 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 hNM2PiAkzpSh for ; Wed, 16 Apr 2014 18:31:24 -0700 (PDT) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id B8C241A0393 for ; Wed, 16 Apr 2014 18:31:24 -0700 (PDT) Received: by mail-ig0-f175.google.com with SMTP id ur14so1750790igb.2 for ; Wed, 16 Apr 2014 18:31:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=8HMTuH1QrbW87sT/vqyx0sveXjAtwPV8X1bkhMFPm0Y=; b=J4YFhTvPbCkxll8d0CCLMn/eV9zsbJUL7EaVYQVfzCE9Pv3/sRwB+mcdF2p84cVFaZ u/Iyj6dh1pI2Ee/aag6XD+YLpMfcZFsFXZ6Jto94YLEPi4LWsD/FaUwXv49e2uEP9P+v 7SYtccrBEf7Mrsg3/dVkt/TFHS5DMHw+4JuFP0xvcF9Qwct2ePvavs0nqJfP1W106eVs YJya4qzv79QYv3lo8wq1Pl0y11YqSC8KXUoIe6cv6YM3d18E6YvCEGW2uCXXLM2tqx+5 O9bblXejhiaSBcvXZHLRX8UtANq3hD2dxYIpL45p0fGBxQZE8blI3Hc+qqmbJ5ITxVpv OksA== 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=8HMTuH1QrbW87sT/vqyx0sveXjAtwPV8X1bkhMFPm0Y=; b=RNrMXdaemzwnBC2pE1BWimODSZpjPvoLphyYqAyDoTbVVg3gsIb2HKNmsH2pzlXAGg crdozZhj5ADupENsBQXziC+nBJUr+hJFZHL8SlxdpLaZcsZSz7fc+Vke2RNYpkbh/TGk oFO63khAMb3PvqYKimZ2ZjJZLo+QV8d25geW6tOp2fTTi7WXQ2YfzpHqMicO6biroP8v oZcupThZjD4Y5OkOMf8xlJIzS/PEuZ8rbWzuudm4/8a6Xeqm6fB97x0P16tGBcQ3JN3B x89sIZ2So/rj/4a9ELDsKNcqBjvVofSPKKutcrch5UvjZKlgsp29ZbJ8Bd8VwqpLcKGO Okjw== X-Gm-Message-State: ALoCoQk/oWwYdD5MYcHacT8Xfixi951j3lQlU7bLEIg3ygZgO2xBKJ3+NDmtFqJC+/Fu9G9yklL+WWKBkuBp6umTcsvNkroB3MH9XS9f32CIRMbT/5oz9UPwka353HTIBCylkGi8XKd4WTm/hngAokdusMF7tDDwAiRLq+DnnX2H7jX/xTghMFfVWnlTmNDPYyBSnZumTJBy X-Received: by 10.50.22.69 with SMTP id b5mr8248450igf.45.1397698281031; Wed, 16 Apr 2014 18:31:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.18.136 with HTTP; Wed, 16 Apr 2014 18:31:00 -0700 (PDT) In-Reply-To: <534ED24E.1070204@thekelleys.org.uk> References: <534BF803.3090600@viagenie.ca> <87wqes3pms.fsf@toke.dk> <534C214F.6010603@viagenie.ca> <878ur67rx2.fsf@toke.dk> <534D383E.2090602@viagenie.ca> <534D4F40.5050102@viagenie.ca> <534D58E7.2050702@viagenie.ca> <9068E42F-3E85-4D2F-AB57-234365CFE1C7@fugue.com> <4631.1397609719@sandelman.ca> <8761maozqq.wl%jch@pps.univ-paris-diderot.fr> <28578.1397616059@sandelman.ca> <878ur5cei7.wl%jch@pps.univ-paris-diderot.fr> <534ED24E.1070204@thekelleys.org.uk> From: Lorenzo Colitti Date: Thu, 17 Apr 2014 10:31:00 +0900 Message-ID: To: Simon Kelley Content-Type: multipart/alternative; boundary=047d7b10cedd8b688b04f732fda0 Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/iZSHkw9E-lUagJg6EW45o9jxRgI Cc: "homenet@ietf.org" Subject: Re: [homenet] Please review the No IPv4 draft 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, 17 Apr 2014 01:31:29 -0000 --047d7b10cedd8b688b04f732fda0 Content-Type: text/plain; charset=UTF-8 On Thu, Apr 17, 2014 at 3:56 AM, Simon Kelley wrote: > My personal feeling is that suppressing IPv4 should be a a DHCPv4 > function, that keeps the go-into-hibernation transition solely in the > DHCPv4 code, it also means the when IPv4 support finally goes, so does > the transition mechanism. > What he said. (And of course, he's one of the people actually implementing this stuff, too.) --047d7b10cedd8b688b04f732fda0 Content-Type: text/html; charset=UTF-8
On Thu, Apr 17, 2014 at 3:56 AM, Simon Kelley <simon@thekelleys.org.uk> wrote:
My personal feeling is that suppressing IPv4 should be a a DHCPv4
function, that keeps the go-into-hibernation transition solely in the
DHCPv4 code, it also means the when IPv4 support finally goes, so does
the transition mechanism.

What he said. (And of course, he's one of the people actually implementing this stuff, too.)
--047d7b10cedd8b688b04f732fda0-- From nobody Wed Apr 16 23:37: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 D378E1A049E for ; Wed, 16 Apr 2014 23:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.272 X-Spam-Level: X-Spam-Status: No, score=-0.272 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272] 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 Dhq6jBXj-J05 for ; Wed, 16 Apr 2014 23:37:42 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [218.241.118.7]) by ietfa.amsl.com (Postfix) with SMTP id 1DE1E1A04A1 for ; Wed, 16 Apr 2014 23:37:38 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: dengguangqing@cnnic.cn Received: from unknown127.0.0.1 (HELO user-think) (127.0.0.1) by 127.0.0.1 with SMTP; Thu, 17 Apr 2014 14:37:28 +0800 Date: Thu, 17 Apr 2014 14:37:28 +0800 From: "Guangqing Deng" To: "Douglas Otis" References: , <64E9ED15-A94D-4D80-9447-80C1E217E19A@gmail.com>, , <4DBFF820-72EE-4369-9837-AE15F81E5410@gmail.com>, , <0C559F1B-6F5B-4357-AFC4-99E46DDCEBB8@gmail.com>, X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 5, 136[cn] Mime-Version: 1.0 Message-ID: <201404171437279947678@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart402471715224_=----" Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/C-jeI0lDvgr5qhf_he-_GAAhj9Q Cc: dnssd , HOMENET Subject: Re: [homenet] [dnssd] IETF-89 WG meeting minutes 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, 17 Apr 2014 06:37:45 -0000 This is a multi-part message in MIME format. ------=_001_NextPart402471715224_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Tm93YWRheXMsIHNpbmNlIHBlb3BsZSBhcmUgYWx3YXlzIGtlZW4gdG8gbG9vayBmb3Igc28gY2Fs bGVkICJjaGVhcCwgZmFzdCwgLi4uLCIgd2lmaSBhY2Nlc3MgcG9pbnRzIGluIHB1YmxpYyBwbGFj ZXMgbGlrZSByZXN0YXVyYW50LCBpdCBpcyByZXBvcnRlZCB0aGF0IHNvbWUgZm9yZ2VkIGFjY2Vz cyBwb2ludHMgYXBwZWFyIHRvIGF0dHJhY3QgcGVvcGxlIHRvIGFjY2VzcyBJbnRlcm5ldCBuZXR3 b3JrIHRocm91Z2ggdGhlbSB3aGVyZSB0aGUgcHJpdmF0ZSBpbmZvcm1hdGlvbiBsaWtlIGNyZWRp dCBjYXJkIG51bWJlciBhbmQgcGFzc3dvcmQgbWF5IGJlIGNvbGxlY3RlZCBieSB0aG9zZSBiYWQg YWNjZXNzIHBvaW50cywgd2hpY2ggbWF5IGJlIGFuIGlzc3VlIG5lZWRpbmcgY29uc2lkZXJhdGlv biB3aGVuIGRlcGxveWluZyBtRE5TLg0KIA0KDQoNCkd1YW5ncWluZyBEZW5nDQpDTk5JQyANCiAN CkZyb206IEhlbm5pbmcgUm9nZ2UNCkRhdGU6IDIwMTQtMDQtMTEgMTQ6NDENClRvOiBEb3VnbGFz IE90aXMNCkNDOiBkbnNzZDsgSE9NRU5FVDsgRG9uIFN0dXJlazsgRGF2ZSBUYWh0DQpTdWJqZWN0 OiBSZTogW2Ruc3NkXSBbaG9tZW5ldF0gSUVURi04OSBXRyBtZWV0aW5nIG1pbnV0ZXMNCk9uIEZy aSwgQXByIDExLCAyMDE0IGF0IDE6NTMgQU0sIERvdWdsYXMgT3RpcyA8ZG91Zy5tdHZpZXdAZ21h aWwuY29tPiB3cm90ZToNCj4gbUROUyBpcyBub3QgZWFzaWx5IGRlcGxveWVkIGF0IGxhcmdlIHNj YWxlIG92ZXIgd2lyZWxlc3Mgd2l0aG91dCBmaWx0ZXJpbmcuICBXaWZpIGhhcyBpbXByb3ZlZCBi eSBvZmZlcmluZyBtaXRpZ2F0aW9uIHN0cmF0ZWdpZXMgbGlrZSBtdWx0aWNhc3QgcXVldWluZyBw ZXIgTiBiZWFjb25zIGFuZCBtdWx0aWNhc3Qgc3BlY2lmaWMgZmlsdGVycy4gIEV2ZW4gc28sIHRo ZXNlIHN0cmF0ZWdpZXMgYXJlIHVubGlrZWx5IG5lZWRlZCBhdCBob21lLiAgSSBtYWtlIGV4dGVu c2l2ZSB1c2Ugb2YgbUROUyB3aXRoaW4gYSBkZW5zZSB3aXJlbGVzcyBzcGVjdHJ1bSBjb250YWlu aW5nIGRvemVucyBvZiBuZWFyYnkgYWNjZXNzIHBvaW50cyB3aXRob3V0IGRpZmZpY3VsdHkgd2hp bGUgdHJhbnNmZXJyaW5nIG11bHRpcGxlIEhEKyBzdHJlYW1zLiAgSSB3b3VsZCBiZSBpbnRlcmVz dGVkIGluIGtub3dpbmcgd2hhdCBwcm9ibGVtcyB5b3UgYXJlIGV4cGVyaWVuY2luZyB3aXRoaW4g eW91ciBob21lLg0KIA0KSXRzIG5vdCBvbmx5IG1ETlMsIGl0cyBhbHNvIEFSUCwgSUNNUHY2IGFu ZCBvdGhlciAibGlua2xvY2FsDQptdWx0aWNhc3QiIHByb3RvY29scyB0aGF0IHdvcmsgYmFkbHkg b3ZlciBsYXJnZSBXaWZpIGxpbmtsYXllcg0KZG9tYWlucy4gTGlua2xvY2FsIG5vcm1hbGx5IG1l YW5zICJmYXN0LCBjaGVhcCwgYXRvbWljLCBpbi1vcmRlciIuLi4NCmlmIHlvdSByZXBsYWNlIGl0 IHdpdGggYSBsYXJnZSB3aXJlbGVzcyBsYXllci0yIGRvbWFpbiwgaXQgYmVjb21lcw0Kc29tZXRo aW5nIHZlcnkgZGlmZmVyZW50Lg0KIA0KSGVubmluZyBSb2dnZQ0KIA0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmRuc3NkIG1haWxpbmcgbGlzdA0KZG5z c2RAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG5zc2QN Cg== ------=_001_NextPart402471715224_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =0A =0A
Nowadays, since people are= always keen to look for so called "cheap, fast, ...," wifi access points = in public places like restaurant, it is reported that some forged access p= oints appear to attract people to access Internet network through them whe= re the private information like credit card number and password may be col= lected by those bad access points, which may be an issue needing considera= tion when deploying mDNS.
=0A
 
=0A
=0A
=0A
Guangqing =0ADeng<= /div>=0A
CNNIC 
&= nbsp;
Date: 2014-04= -11 14:41
Subject: Re: [dnssd] [ho= menet] IETF-89 WG meeting minutes
On Fri, Apr = 11, 2014 at 1:53 AM, Douglas Otis <doug.mtview@gmail.com> wrote:=0A
> mDNS is not easily deployed at large scale over wireless wi= thout filtering.  Wifi has improved by offering mitigation strategies= like multicast queuing per N beacons and multicast specific filters. = ; Even so, these strategies are unlikely needed at home.  I make exte= nsive use of mDNS within a dense wireless spectrum containing dozens of ne= arby access points without difficulty while transferring multiple HD+ stre= ams.  I would be interested in knowing what problems you are experien= cing within your home.
=0A
 
=0A
Its not only mDNS,= its also ARP, ICMPv6 and other "linklocal
=0A
multicast" protoco= ls that work badly over large Wifi linklayer
=0A
domains. Linkloc= al normally means "fast, cheap, atomic, in-order"...
=0A
if you r= eplace it with a large wireless layer-2 domain, it becomes
=0A
so= mething very different.
=0A
 
=0A
Henning Rogge=0A
 
=0A
____________________________________________= ___
=0A
dnssd mailing list
=0A
dnssd@ietf.org
=0Ahttps://www.ietf.org/mailman/listinfo/dnssd
=0A
= =0A ------=_001_NextPart402471715224_=------ From nobody Thu Apr 17 06:55: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 A96CD1A0218 for ; Thu, 17 Apr 2014 06:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 qWe-0dIxCE1f for ; Thu, 17 Apr 2014 06:55:49 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id C5D1F1A0127 for ; Thu, 17 Apr 2014 06:55:47 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id 6A0AF1B8568; Thu, 17 Apr 2014 15:55:43 +0200 (CEST) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 51617C80A9; Thu, 17 Apr 2014 15:55:43 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Thu, 17 Apr 2014 15:55:43 +0200 From: To: Michael Richardson , "homenet@ietf.org" Date: Thu, 17 Apr 2014 15:55:41 +0200 Thread-Topic: [homenet] Please review the No IPv4 draft Thread-Index: Ac9ZdOX5WrRfKKprRe+IgMB/cx/ubQAzw9Rw Message-ID: <94C682931C08B048B7A8645303FDC9F36F56FCB495@PUEXCB1B.nanterre.francetelecom.fr> References: <534BF803.3090600@viagenie.ca> <87wqes3pms.fsf@toke.dk> <534C214F.6010603@viagenie.ca> <878ur67rx2.fsf@toke.dk> <534D383E.2090602@viagenie.ca> <534D4F40.5050102@viagenie.ca> <534D58E7.2050702@viagenie.ca> <9068E42F-3E85-4D2F-AB57-234365CFE1C7@fugue.com> <20140416002851.1FBA013CD524@rock.dv.isc.org> <20492.1397653666@sandelman.ca> In-Reply-To: <20492.1397653666@sandelman.ca> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.4.9.220919 Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/U8ClcpViMrDkpl5pLBWPBXz-YXw Subject: Re: [homenet] Please review the No IPv4 draft 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, 17 Apr 2014 13:55:52 -0000 Dear Michael, all, Please see inline. Cheers, Med >-----Message d'origine----- >De=A0: homenet [mailto:homenet-bounces@ietf.org] De la part de Michael >Richardson >Envoy=E9=A0: mercredi 16 avril 2014 15:08 >=C0=A0: homenet@ietf.org >Objet=A0: Re: [homenet] Please review the No IPv4 draft > > >{I would love a description from Apple and Microsoft of how their >layer-2/layer-3 address discovery/configurartion systems already interact} > >Philip Homburg wrote: > > Does that include all edge cases and the user interface? > > > I.e. DHCPv4 has configured an address and by mistake a RA orders IPv= 4 > > to be > > shutdown. Do you just shutdown IPv4? Does your code parse the output >of > > ifconfig to figure out if the interface was configured? > >No, and no. > >The order is not to shutdown v4. The suggestion is to stop DHCPv4, if it >hasn't succeeded, and assume that there isn't any IPv4 for any downstream >devices. > >Ideally the device will not announce an IPv4 default route if it hasn't go= t >one itself. [Med] This is not a valid generic statement. Consider the DS-Lite model (RF= C6333): there is no dhcpv4 client in the CPE at all + no assigned IPv4 addr= ess in the wan side, but still IPv4 connectivity is offered to connected ho= sts. DHCPv4 client is disabled when the CPE detects it is attaching the net= work using DS-Lite. The no-dhcpv4 explicit signal is not required for this = case for example. From nobody Thu Apr 17 07:22: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 5BF6E1A00B1 for ; Thu, 17 Apr 2014 07:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 bigeLl9ueMDX for ; Thu, 17 Apr 2014 07:22:17 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9827A1A00A3 for ; Thu, 17 Apr 2014 07:22:17 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:2520:ef8a:477:622f]) by jazz.viagenie.ca (Postfix) with ESMTPSA id D7DBF403D3 for ; Thu, 17 Apr 2014 10:22:13 -0400 (EDT) Message-ID: <534FE395.1050702@viagenie.ca> Date: Thu, 17 Apr 2014 10:22:13 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: homenet@ietf.org References: <534BF803.3090600@viagenie.ca> <87wqes3pms.fsf@toke.dk> <534C214F.6010603@viagenie.ca> <878ur67rx2.fsf@toke.dk> <534D383E.2090602@viagenie.ca> <534D4F40.5050102@viagenie.ca> <534D58E7.2050702@viagenie.ca> <9068E42F-3E85-4D2F-AB57-234365CFE1C7@fugue.com> <20140416002851.1FBA013CD524@rock.dv.isc.org> <20492.1397653666@sandelman.ca> <20140416221241.1958E13F33B1@rock.dv.isc.org> In-Reply-To: <20140416221241.1958E13F33B1@rock.dv.isc.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/s-tMZv9p_eBnvotu6RZYflqr6Hk Subject: Re: [homenet] Please review the No IPv4 draft 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, 17 Apr 2014 14:22:24 -0000 Le 2014-04-16 18:12, Mark Andrews a écrit : > With the currently defined states yes you shut down everything for 1 and > 3. You don't shutdown for 0 and 2. I think some here want a currently > undefined state, no dhcp but local connectivity. > > I would switch 1 and 2 around so that you go from most (0) to least (3) > IPv4 support on the interface. > > Currently it is: > > 0 full IPv4 connectivity > 1 all IPv4 off on the interface > 2 local (link/site not global) connectivity only on the interface > 3 no IPv4 on the machine. Uh, no. The levels are in strictly increasing order. 2 includes everything in 1, plus some more: 2 - No IPv4 upstream, local IPv4 restricted: Same semantics as value 1, with the following additions: 2 deals with propagation to downstream interfaces. It has nothing to do with link or site local stuff. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Thu Apr 17 07:24: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 59E761A00DD for ; Thu, 17 Apr 2014 07:24:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.573 X-Spam-Level: X-Spam-Status: No, score=-1.573 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_32=0.6, RP_MATCHES_RCVD=-0.272, 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 zzn7zxFIDvge for ; Thu, 17 Apr 2014 07:24:32 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9BDC81A00A3 for ; Thu, 17 Apr 2014 07:24:32 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:2520:ef8a:477:622f]) by jazz.viagenie.ca (Postfix) with ESMTPSA id EB5B7403D3 for ; Thu, 17 Apr 2014 10:24:28 -0400 (EDT) Message-ID: <534FE41C.50008@viagenie.ca> Date: Thu, 17 Apr 2014 10:24:28 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: homenet@ietf.org References: <534BF803.3090600@viagenie.ca> <87wqes3pms.fsf@toke.dk> <534C214F.6010603@viagenie.ca> <878ur67rx2.fsf@toke.dk> <534D383E.2090602@viagenie.ca> <534D4F40.5050102@viagenie.ca> <534D58E7.2050702@viagenie.ca> <534E7C48.6070001@viagenie.ca> <4C9B747D-451A-456F-BF59-E447583A04E6@fugue.com> <534EAEE6.1060305@thekelleys.org.uk> In-Reply-To: <534EAEE6.1060305@thekelleys.org.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/jxEcc0caUdgcUPMo7Yw2gepxxAQ Subject: Re: [homenet] Please review the No IPv4 draft 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, 17 Apr 2014 14:24:33 -0000 Le 2014-04-16 12:25, Simon Kelley a écrit : > Android uses dhcpcd as its DHCP client. Thought about this some more... Doesn't dhcpcd implement everything in a single daemon? i.e., DHCPv4, DHCPv4, IPv4LL, IPv6 RS? If so, then it would be easy for one protocol to affect another, wouldn't it? Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Thu Apr 17 12:06: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 B793F1A01AD for ; Thu, 17 Apr 2014 12:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.163 X-Spam-Level: X-Spam-Status: No, score=-2.163 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=0.01] 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 57A6i2TH1lAe for ; Thu, 17 Apr 2014 12:06:45 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id AE5F61A0182 for ; Thu, 17 Apr 2014 12:06:45 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id CAF7820029; Thu, 17 Apr 2014 15:07:03 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 76C8963ABD; Thu, 17 Apr 2014 15:06:38 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 63E2463ABA; Thu, 17 Apr 2014 15:06:38 -0400 (EDT) From: Michael Richardson To: mohamed.boucadair@orange.com In-Reply-To: <94C682931C08B048B7A8645303FDC9F36F56FCB495@PUEXCB1B.nanterre.francetelecom.fr> References: <534BF803.3090600@viagenie.ca> <87wqes3pms.fsf@toke.dk> <534C214F.6010603@viagenie.ca> <878ur67rx2.fsf@toke.dk> <534D383E.2090602@viagenie.ca> <534D4F40.5050102@viagenie.ca> <534D58E7.2050702@viagenie.ca> <9068E42F-3E85-4D2F-AB57-234365CFE1C7@fugue.com> <20140416002851.1FBA013CD524@rock.dv.isc.org> <20492.1397653666@sandelman.ca> <94C682931C08B048B7A8645303FDC9F36F56FCB495@PUEXCB1B.nanterre.francetelecom.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 Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/zRNILGsFKbql60Osfw_iT7QlJ50 Cc: "homenet@ietf.org" Subject: Re: [homenet] Please review the No IPv4 draft 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, 17 Apr 2014 19:06:50 -0000 --=-=-= wrote: >> The order is not to shutdown v4. The suggestion is to stop DHCPv4, if it >> hasn't succeeded, and assume that there isn't any IPv4 for any downstream >> devices. >> >> Ideally the device will not announce an IPv4 default route if it hasn't got >> one itself. > [Med] This is not a valid generic statement. Consider the DS-Lite model > (RFC6333): there is no dhcpv4 client in the CPE at all + no assigned > IPv4 address in the wan side, but still IPv4 connectivity is offered to > connected hosts. DHCPv4 client is disabled when the CPE detects it is > attaching the network using DS-Lite. The no-dhcpv4 explicit signal is > not required for this case for example. The device still has an default IPv4 route. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBU1AmPoqHRg3pndX9AQLvdwP+Pp4RYSqMxwIUXQLJk1Hz1h8FOKyVNIEQ E988nlXKZWJpOgeuG3dkKYCOhDRSFSj5wkG85ncYapeXFm4vhay9oPnwL0W0ZKWE 5wnL20hrc9V26OG/jhiF9NFGe5LfCrzGQfuDX3Tpz8Fq7OMUvDHqdcaAADMFdO3i 9neM17zpZeg= =yBjE -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Apr 17 14:14: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 24F3A1A0119 for ; Thu, 17 Apr 2014 14:14:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 1nAT89oxQ3Dw for ; Thu, 17 Apr 2014 14:14:45 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id E14A91A0133 for ; Thu, 17 Apr 2014 14:14:44 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP id 7A08C34941E; Thu, 17 Apr 2014 21:14:40 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 76431160064; Thu, 17 Apr 2014 21:16:55 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 44963160060; Thu, 17 Apr 2014 21:16:55 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 0280D140ACE1; Fri, 18 Apr 2014 07:14:38 +1000 (EST) To: Simon Perreault From: Mark Andrews References: <534BF803.3090600@viagenie.ca> <87wqes3pms.fsf@toke.dk> <534C214F.6010603@viagenie.ca> <878ur67rx2.fsf@toke.dk> <534D383E.2090602@viagenie.ca> <534D4F40.5050102@viagenie.ca> <534D58E7.2050702@viagenie.ca> <9068E42F-3E85-4D2F-AB57-234365CFE1C7@fugue.com> <20140416002851.1FBA013CD524@rock.dv.isc.org> <20492.1397653666@sandelman.ca> <20140416221241.1958E13F33B1@rock.dv.isc.org> <534FE395.1050702@viagenie.ca> In-reply-to: Your message of "Thu, 17 Apr 2014 10:22:13 -0400." <534FE395.1050702@viagenie.ca> Date: Fri, 18 Apr 2014 07:14:37 +1000 Message-Id: <20140417211438.0280D140ACE1@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/vAg2uf7kVrA3hQpDFUwQdWDsJiI Cc: homenet@ietf.org Subject: Re: [homenet] Please review the No IPv4 draft 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, 17 Apr 2014 21:14:50 -0000 In message <534FE395.1050702@viagenie.ca>, Simon Perreault writes: > Le 2014-04-16 18:12, Mark Andrews a =E9crit : > > With the currently defined states yes you shut down everything for 1 and > > 3. You don't shutdown for 0 and 2. I think some here want a currently > > undefined state, no dhcp but local connectivity. > > = > > > I would switch 1 and 2 around so that you go from most (0) to least (3) > > IPv4 support on the interface. > > = > > > Currently it is: > > = > > > 0 full IPv4 connectivity > > 1 all IPv4 off on the interface > > 2 local (link/site not global) connectivity only on the interface > > 3 no IPv4 on the machine. > > Uh, no. The levels are in strictly increasing order. 2 includes > everything in 1, plus some more: > > 2 - No IPv4 upstream, local IPv4 restricted: Same semantics as value > 1, with the following additions: > > 2 deals with propagation to downstream interfaces. It has nothing to do > with link or site local stuff. Part of the problem here is that "upstream" is the only "interface" for singlely attached devices other than loopback. There is no "only local connectivity is available" step for such nodes. 0 - IPv4 fully enabled: This is equivalent to the absence of the No- IPv4 option. It is included here so that a DHCPv6 server can explicitly re-enable IPv4 access by including it in a Reply message following a Reconfigure, or similarly by a router in a spontaneous Router Advertisement. 1 - No IPv4 upstream: Any kind of IPv4 connectivity is unavailable on the link on which the option is received. Therefore, any attempts to provision IPv4 by the host or to use IPv4 in any fashion, on that link, will be useless. IPv4 MAY be dropped, blocked, or otherwise ignored on that link. Mark > Simon > -- = > > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Apr 17 19:46: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 1DC951A0194 for ; Thu, 17 Apr 2014 19:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 WNkirlVjLELN for ; Thu, 17 Apr 2014 19:46:25 -0700 (PDT) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 705891A001E for ; Thu, 17 Apr 2014 19:46:25 -0700 (PDT) Received: by mail-yk0-f173.google.com with SMTP id 10so1022668ykt.4 for ; Thu, 17 Apr 2014 19:46:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=swxf5/iTchnu4+N/5R50GLgoEiDSQZ4wcUjzaSmSASM=; b=XjCKEAwlfxTaIIn0+I1gfXJf+dW2dkx3DCEaXpygMCvEn5frm/x7Vk8l+uDguV78/E gUI7ZfGPoE4pgBXis6j05UetP7qOLxdKXFpmVoVrSGmg1jN3ngdWoJMEZsSyLJJDFGWr iawamtxKZrUy7f5b12rk4SvnQFr9nccVaNDdOONfLD6P2ER4FX1wsmWj/VBsMMgcQf1m qV5CBFIL2TQKSaWhg0Q+KRVOmrPBQjV+LiZRtgPW8RbGbDp4DwiFa4gBttXlarSA7Yj3 qUJU2sVxSXVXqwoZlDtA1pw4TCdCjCGme6cOVz2RrfAf3pezDqpZYfo5/uJV9Lz6GJ6s L3qQ== X-Received: by 10.236.177.100 with SMTP id c64mr27945319yhm.30.1397789181643; Thu, 17 Apr 2014 19:46:21 -0700 (PDT) Received: from [192.168.124.105] ([186.188.80.235]) by mx.google.com with ESMTPSA id e70sm51465155yhk.9.2014.04.17.19.46.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Apr 2014 19:46:19 -0700 (PDT) Message-ID: <535091FB.9010203@gmail.com> Date: Thu, 17 Apr 2014 22:16:19 -0430 From: Alejandro Acosta User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: homenet@ietf.org References: <534BF803.3090600@viagenie.ca> In-Reply-To: <534BF803.3090600@viagenie.ca> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/Yuj6-Ae4fxr5RgCtirZTzh8zTsA Subject: Re: [homenet] Please review the No IPv4 draft 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, 18 Apr 2014 02:46:27 -0000 Hi, Nice idea & draft. I like the idea of having the No-IPv4 option for DHCPv6. I don't like the idea of having this option in a v4 world; mainly because in mix networks where you might have some folks which only speak IPv4, imagine a case where this option is sent by a DHCPv4 to a client who do not understand v6. Of course, probably the client won't understand the option and won't turn off IPv4. There is also the chance that this is a modern OS but for some reason IPv6 was disable in the host, yes, it will understand the option No-VP6 (sent by a dhcp4). Last but not least, following this thread some of you mentioned filtering (RA, DHCP OFFER) in the switch can prevent some unwanted situations.., there are also other networks that are switch-less. Regards, Alejandro Acosta, El 4/14/2014 10:30 AM, Simon Perreault escribió: > Dearest HOMENET, > > We are soliciting reviews for this SUNSET4 draft: > > http://tools.ietf.org/html/draft-ietf-sunset4-noipv4-00 > > In a nutshell, it defines DHCPv6 and RA options indicating to the host > that IPv4 is not available. Since home networks are among those likely > to see its use, reviews coming from HOMENET would be of tremendous help. > > Thanks, > Simon > From nobody Thu Apr 17 20:49:37 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 9EB601A00C0 for ; Thu, 17 Apr 2014 20:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.05 X-Spam-Level: X-Spam-Status: No, score=-1.05 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, J_CHICKENPOX_32=0.6, RP_MATCHES_RCVD=-0.272, 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 McoZ8bNsr451 for ; Thu, 17 Apr 2014 20:49:31 -0700 (PDT) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 3D4E11A00A5 for ; Thu, 17 Apr 2014 20:49:31 -0700 (PDT) Received: by mail-ob0-f175.google.com with SMTP id wp4so1358527obc.20 for ; Thu, 17 Apr 2014 20:49:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=mNAGRk+iwuizoS+YX403bgj+q5Ue0DCYXruf+WjBny0=; b=oP8VhIz4bWlJLx+vwrG+WfE/4GX+4V3xqevW8EY8fGCMMI91gSlFwU8esWmjAVzBlP ei1IsvWScvz5l/nB3FI71M94Wy0H0EI63cHymR7iRngGkg8Xr5JN/4JQ19mozb2yjs1w +8nMUFt7jAvLDOq/KKU6cpQAM6VmoMeLZpAxxdwLVwl2YASmJ7aCRowrha+oMuUQH0nP UcCaWMIFyQOnD9lJ96aQYP9UAWUrz6lfa1rLCDRiNUbOyuB6sCadlPABuLmO5xI4KBiN L+oTyOoDXQ/2GxioAA4Plz6u5Lrg/LlGVRIZRcfBThkMNBX0+gyisfJ9spMeF+XZjz9r uUdA== 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=mNAGRk+iwuizoS+YX403bgj+q5Ue0DCYXruf+WjBny0=; b=BLZ/6drVd5srLf1bqHI/a2fXjlpLCdnIQG/S4digNMl4vRNoIbZVpURKphD0FrapFq zfpJcm1IM1yHefErlhb41S/P6u3hszituOCihvYTrTKGOPazGvjQuy8lMgMQ0nny7FjH EjLnB3vrfxiE5tdB3UdhyxhN5mJ2gTD5uQ6ukHdL4GB2/UZBLojQiwyRVb1xUU1/884L adujTsKQQKkn7CwPlIOkkCVQ3fDdmE9v5VR1HR85awRXazg/DcaQMSbr+HB+whVtJIHz lJ7K/EfI6p94By/uW4X1HbmIxK5fWyKhZHoBW9e1rubczqstHndyfUT2YjxanHh6sT76 vlmg== X-Gm-Message-State: ALoCoQlwJ7NPLkUoNvs3JAOVAOxkqsKYH5N1Ubk7rKfoLVmdEfKdiL3D0A+sL0UGlwwJtRjU+Z2r6yovTNJT7ZnfR2gzfw1XiAvQFDcgKPHSkYPkjKN3iKfPSgIdjPCuuvvUolT7dFDNFg8X88wokVQmd2IgKb/O+r9h27oe/gzcfXATwA61AP5ZfIUdTZpdNRXYzl7Hxdwq X-Received: by 10.60.76.194 with SMTP id m2mr10547803oew.47.1397792967192; Thu, 17 Apr 2014 20:49:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.89.229 with HTTP; Thu, 17 Apr 2014 20:49:07 -0700 (PDT) In-Reply-To: <534FE41C.50008@viagenie.ca> References: <534BF803.3090600@viagenie.ca> <87wqes3pms.fsf@toke.dk> <534C214F.6010603@viagenie.ca> <878ur67rx2.fsf@toke.dk> <534D383E.2090602@viagenie.ca> <534D4F40.5050102@viagenie.ca> <534D58E7.2050702@viagenie.ca> <534E7C48.6070001@viagenie.ca> <4C9B747D-451A-456F-BF59-E447583A04E6@fugue.com> <534EAEE6.1060305@thekelleys.org.uk> <534FE41C.50008@viagenie.ca> From: Lorenzo Colitti Date: Fri, 18 Apr 2014 12:49:07 +0900 Message-ID: To: Simon Perreault Content-Type: multipart/alternative; boundary=047d7b33cea647959e04f7490989 Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/jD2QPS2kk1CZHS_3bdVAwugYXJo Cc: Erik Kline , "homenet@ietf.org" Subject: Re: [homenet] Please review the No IPv4 draft 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, 18 Apr 2014 03:49:35 -0000 --047d7b33cea647959e04f7490989 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Apr 17, 2014 at 11:24 PM, Simon Perreault < simon.perreault@viagenie.ca> wrote: > Le 2014-04-16 12:25, Simon Kelley a =C3=A9crit : > > Android uses dhcpcd as its DHCP client. > > Thought about this some more... Doesn't dhcpcd implement everything in a > single daemon? i.e., DHCPv4, DHCPv4, IPv4LL, IPv6 RS? If so, then it > would be easy for one protocol to affect another, wouldn't it? In practice, you can't use dhcpcd for autoconf because it doesn't support privacy addresses or removing the default route when the RA lifetime expires. (Or at least, the 6.3.2 version I downloaded today and ran on Debian stable didn't seem to support this). So you still need to run kernel autoconf, at which point you might as well disable dhdpcd's RS processing since you probably don't want both the kernel and dhcpcd to be running autoconf. --047d7b33cea647959e04f7490989 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Apr 17, 2014 at 11:24 PM, Simon Perreault <simon.perreault@v= iagenie.ca> wrote:
Le 2014-04-16 12:25, Simon Kelley a =C3=A9crit :
> Android uses dhcpcd as its DHCP client.

Thought about this some more... Doesn't dhcpcd implement everything in = a
single daemon? i.e., DHCPv4, DHCPv4, IPv4LL, IPv6 RS? If so, then it
would be easy for one protocol to affect another, wouldn't it?

In practice, you can't use dhcpcd for autoconf = because it doesn't support privacy addresses or removing the default ro= ute when the RA lifetime expires. (Or at least, the 6.3.2 version I downloa= ded today and ran on Debian stable didn't seem to support this).

So you still need to run kernel autoconf, at which poin= t you might as well disable dhdpcd's RS processing since you probably d= on't want both the kernel and dhcpcd to be running autoconf.
--047d7b33cea647959e04f7490989-- From nobody Fri Apr 18 00:58: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 EABB71A01B1 for ; Fri, 18 Apr 2014 00:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2] 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 8GEuagGpB2Sz for ; Fri, 18 Apr 2014 00:58:22 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id C27861A02C2 for ; Fri, 18 Apr 2014 00:58:20 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #76) id m1Wb3gd-0000BrC; Fri, 18 Apr 2014 09:58:15 +0200 Message-Id: To: Alejandro Acosta From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <534BF803.3090600@viagenie.ca> <535091FB.9010203@gmail.com> In-reply-to: Your message of "Thu, 17 Apr 2014 22:16:19 -0430 ." <535091FB.9010203@gmail.com> Date: Fri, 18 Apr 2014 09:58:14 +0200 Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/pcPfsl5UUiWKM_atLYdsbghjB58 Cc: homenet@ietf.org Subject: Re: [homenet] Please review the No IPv4 draft 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, 18 Apr 2014 07:58:25 -0000 In your letter dated Thu, 17 Apr 2014 22:16:19 -0430 you wrote: > I like the idea of having the No-IPv4 option for DHCPv6. I don't like >the idea of having this option in a v4 world; mainly because in mix >networks where you might have some folks which only speak IPv4, imagine >a case where this option is sent by a DHCPv4 to a client who do not >understand v6. Of course, probably the client won't understand the >option and won't turn off IPv4. There is also the chance that this is a >modern OS but for some reason IPv6 was disable in the host, yes, it will >understand the option No-VP6 (sent by a dhcp4). As far as I understand, this draft addresses the situation where the network doesn't offer IPv4 in the first place. So any IPv4-only host would have no internet connectivity anyhow, whether it processes the option or not. From nobody Fri Apr 18 05:48: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 F2E0F1A01BB for ; Fri, 18 Apr 2014 05:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 RGs3sgU72Mxu for ; Fri, 18 Apr 2014 05:48:44 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2056A1A011B for ; Fri, 18 Apr 2014 05:48:44 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:349d:fe5f:bc57:89]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 189884021E; Fri, 18 Apr 2014 08:48:40 -0400 (EDT) Message-ID: <53511F27.8090201@viagenie.ca> Date: Fri, 18 Apr 2014 08:48:39 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Mark Andrews References: <534BF803.3090600@viagenie.ca> <87wqes3pms.fsf@toke.dk> <534C214F.6010603@viagenie.ca> <878ur67rx2.fsf@toke.dk> <534D383E.2090602@viagenie.ca> <534D4F40.5050102@viagenie.ca> <534D58E7.2050702@viagenie.ca> <9068E42F-3E85-4D2F-AB57-234365CFE1C7@fugue.com> <20140416002851.1FBA013CD524@rock.dv.isc.org> <20492.1397653666@sandelman.ca> <20140416221241.1958E13F33B1@rock.dv.isc.org> <534FE395.1050702@viagenie.ca> <20140417211438.0280D140ACE1@rock.dv.isc.org> In-Reply-To: <20140417211438.0280D140ACE1@rock.dv.isc.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/wUAnL8T7g2CG03JJVAzkqW_rWW4 Cc: homenet@ietf.org Subject: Re: [homenet] Please review the No IPv4 draft 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, 18 Apr 2014 12:48:49 -0000 Le 2014-04-17 17:14, Mark Andrews a écrit : >>> 0 full IPv4 connectivity >>> 1 all IPv4 off on the interface >>> 2 local (link/site not global) connectivity only on the interface >>> 3 no IPv4 on the machine. >> >> Uh, no. The levels are in strictly increasing order. 2 includes >> everything in 1, plus some more: >> >> 2 - No IPv4 upstream, local IPv4 restricted: Same semantics as value >> 1, with the following additions: >> >> 2 deals with propagation to downstream interfaces. It has nothing to do >> with link or site local stuff. > > Part of the problem here is that "upstream" is the only "interface" > for singlely attached devices other than loopback. There is no > "only local connectivity is available" step for such nodes. Correct. For such nodes, 1 == 2. Is that a problem? It's still a stairway going up, with steps 1 and 2 being at the same height for a subset of nodes. Simon > > 0 - IPv4 fully enabled: This is equivalent to the absence of the No- > IPv4 option. It is included here so that a DHCPv6 server can > explicitly re-enable IPv4 access by including it in a Reply > message following a Reconfigure, or similarly by a router in a > spontaneous Router Advertisement. > > 1 - No IPv4 upstream: Any kind of IPv4 connectivity is unavailable > on the link on which the option is received. Therefore, any > attempts to provision IPv4 by the host or to use IPv4 in any > fashion, on that link, will be useless. IPv4 MAY be dropped, > blocked, or otherwise ignored on that link. > > Mark -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Fri Apr 18 05:51: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 DD83F1A01CF for ; Fri, 18 Apr 2014 05:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.573 X-Spam-Level: X-Spam-Status: No, score=-1.573 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_32=0.6, RP_MATCHES_RCVD=-0.272, 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 eLV4sx_3IR72 for ; Fri, 18 Apr 2014 05:51:13 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8AF661A01D4 for ; Fri, 18 Apr 2014 05:51:12 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:349d:fe5f:bc57:89]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 755E44021E; Fri, 18 Apr 2014 08:51:08 -0400 (EDT) Message-ID: <53511FBC.5060307@viagenie.ca> Date: Fri, 18 Apr 2014 08:51:08 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Lorenzo Colitti References: <534BF803.3090600@viagenie.ca> <87wqes3pms.fsf@toke.dk> <534C214F.6010603@viagenie.ca> <878ur67rx2.fsf@toke.dk> <534D383E.2090602@viagenie.ca> <534D4F40.5050102@viagenie.ca> <534D58E7.2050702@viagenie.ca> <534E7C48.6070001@viagenie.ca> <4C9B747D-451A-456F-BF59-E447583A04E6@fugue.com> <534EAEE6.1060305@thekelleys.org.uk> <534FE41C.50008@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/kgwV_FMn8Hr26z5Kdm5KI6zzTH8 Cc: Erik Kline , "homenet@ietf.org" Subject: Re: [homenet] Please review the No IPv4 draft 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, 18 Apr 2014 12:51:14 -0000 Le 2014-04-17 23:49, Lorenzo Colitti a Ă©crit : > On Thu, Apr 17, 2014 at 11:24 PM, Simon Perreault > > wrote: > > Le 2014-04-16 12:25, Simon Kelley a Ă©crit : > > Android uses dhcpcd as its DHCP client. > > Thought about this some more... Doesn't dhcpcd implement everything in a > single daemon? i.e., DHCPv4, DHCPv4, IPv4LL, IPv6 RS? If so, then it > would be easy for one protocol to affect another, wouldn't it? > > > In practice, you can't use dhcpcd for autoconf because it doesn't > support privacy addresses or removing the default route when the RA > lifetime expires. (Or at least, the 6.3.2 version I downloaded today and > ran on Debian stable didn't seem to support this). > > So you still need to run kernel autoconf, at which point you might as > well disable dhdpcd's RS processing since you probably don't want both > the kernel and dhcpcd to be running autoconf. Got it. So, summarizing, for Android, DHCPv4 and DHCPv6 options would likely not be problematic, but an RA option likely would. Thanks, Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Fri Apr 18 06:24: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 446681A0152 for ; Fri, 18 Apr 2014 06:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 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.272, 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 r03grId5FGAz for ; Fri, 18 Apr 2014 06:24:03 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id CF9A11A01D4 for ; Fri, 18 Apr 2014 06:24:02 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id as1so1580082iec.39 for ; Fri, 18 Apr 2014 06:23:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OdlisZgmSeXOTKZa/kOBmqJVgGDBg/DJuMDiZuMduy4=; b=hdvHtMnNdm3Fatfklxppe0KYRheRL1Vz980NxAWj5sQVxFNnVKO2+iJ6DiVKFDK94Z XUxsAI6RD9xuE4plxDGRfT5XHHRhRSFgoHX06GiAqUqsm/9zJVewdD9CYLK8u0Rdi84E I2m6asYI6BiDWyxsxtdPYGHx3vFZQ2v0FN7UTTrx7IGgLMspiqD+xXMeU2p1qYgZbwNi foRBjVPz93jlG4eHcnSTaipWqiE461/5geiTRRpoDfe0bLhJfxw3VuX+vDQVzEuhDv7h gR8xR91YfesIjLinVY67r6TxwZWNyraylqlbOOTAPaVbPUjGhwD5svIBRrQMOD4bvivV MVww== 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:date :message-id:subject:from:to:cc:content-type; bh=OdlisZgmSeXOTKZa/kOBmqJVgGDBg/DJuMDiZuMduy4=; b=TRciCWPx1ryCtOJVUZOe41bLqsnRmEX2DEqqQyp5y7Ux5hQBDSpDPLzucGfsKapub6 b0FNTDhb4MYEa5fqbsFErY7pVAWQVp6ZgtKheuaB8KTpz0pmvACHiPh7gUymN7Q6Z5o/ q3Z0L5kZ/b7Hb0v7b0uSvGbvaD3NiOaTeZm2Jm4KED/9BB0LXbsdIL+/oeGsP+QJQADf vphWHPT1gSK2KxiHEWwFIZeuq4QK55dgLgEqbn/UZc+EqvU2tmd276KJgnHaS1u8xgib HaL+gCd51VBTa/y/zf3xHXEHEtGSYHaHxEZYPkkBq04LYQfGhhbju6jZjTfLlVWNFvRX 2cBA== X-Gm-Message-State: ALoCoQlNITlDVqjshQQcQVDB4eoWNHo1f14Dlar2TBFtwCrpHwauk5jLCGo0j/Dh4uPkHKs6/yogDMKsZH8HWlzWEAvYLlzXdfps/fsIojEaM20q9Z5jrg6x24xfTwxWPxg69/ppWF8rAmqVyexbPd+W7Ax0aD4XFXYLFNS5xx/52g5s1qz0LO6GTS1c84f42kz9nmqFLNkF MIME-Version: 1.0 X-Received: by 10.50.122.8 with SMTP id lo8mr3868396igb.31.1397827438652; Fri, 18 Apr 2014 06:23:58 -0700 (PDT) Received: by 10.64.18.136 with HTTP; Fri, 18 Apr 2014 06:23:58 -0700 (PDT) Received: by 10.64.18.136 with HTTP; Fri, 18 Apr 2014 06:23:58 -0700 (PDT) In-Reply-To: <53511FBC.5060307@viagenie.ca> References: <534BF803.3090600@viagenie.ca> <87wqes3pms.fsf@toke.dk> <534C214F.6010603@viagenie.ca> <878ur67rx2.fsf@toke.dk> <534D383E.2090602@viagenie.ca> <534D4F40.5050102@viagenie.ca> <534D58E7.2050702@viagenie.ca> <534E7C48.6070001@viagenie.ca> <4C9B747D-451A-456F-BF59-E447583A04E6@fugue.com> <534EAEE6.1060305@thekelleys.org.uk> <534FE41C.50008@viagenie.ca> <53511FBC.5060307@viagenie.ca> Date: Fri, 18 Apr 2014 22:23:58 +0900 Message-ID: From: Lorenzo Colitti To: Simon Perreault Content-Type: multipart/alternative; boundary=089e015384fef0517b04f7510fa5 Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/f77fqJxNI0xdvW_kIGoBxEC07CM Cc: Erik Kline , homenet@ietf.org Subject: Re: [homenet] Please review the No IPv4 draft 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, 18 Apr 2014 13:24:07 -0000 --089e015384fef0517b04f7510fa5 Content-Type: text/plain; charset=UTF-8 On 18 Apr 2014 21:51, "Simon Perreault" wrote: > Got it. So, summarizing, for Android, DHCPv4 and DHCPv6 options would > likely not be problematic, but an RA option likely would. A DHCPv6 option would also be problematic because android doesn't support DHCPv6. (Support for IPv6-only networks is being worked on, but it will use RDNSS). A DHCPv4 option would be better. --089e015384fef0517b04f7510fa5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 18 Apr 2014 21:51, "Simon Perreault" <simon.perreault@viagenie.ca>= ; wrote:
> Got it. So, summarizing, for Android, DHCPv4 and DHCPv6 options would<= br> > likely not be problematic, but an RA option likely would.

A DHCPv6 option would also be=C2=A0 problematic because andr= oid doesn't support DHCPv6. (Support for IPv6-only networks is being wo= rked on, but it will use RDNSS).

A DHCPv4 option would be better.

--089e015384fef0517b04f7510fa5-- From nobody Fri Apr 18 07:27: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 B94A51A0309 for ; Fri, 18 Apr 2014 07:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-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, GB_I_LETTER=-2, 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 R00RRpmmYhTU for ; Fri, 18 Apr 2014 07:27:29 -0700 (PDT) Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 485A01A01B6 for ; Fri, 18 Apr 2014 07:27:29 -0700 (PDT) Received: by mail-yk0-f171.google.com with SMTP id q9so1439498ykb.16 for ; Fri, 18 Apr 2014 07:27:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=mUYO94spScohxLgETntYGKU3jo7YgaK+ggOsm3/dZXE=; b=dsT4a7vyG/UrA587H9VLHDTGAMY22I4N5albDYt0Xgl8kJB0OU7pTSdPqybQ5vsPBb hzAyWEhdTFAbNs8wvfFYfjlRDTnp8UDaT05ezN1QizQjWYdMTO5zdc03VVZHM2X4BQye cRUkmtk3zp/fM3I4ekqDR9kHTwEYMyjocr3x0na7fDXxwutzI1Au6FwM7K+dnf87PNvF It6XbATdfP1AutE0lPevFacVPNLrJtPwwSwVwQ3tPYBxJ71zs2jwgblg3+vHy58WuG2K 3hC3Refd9l39wOXcPlJgfU8RyF3M5bSgOZ/dPtXQJwaphLGx27gK2+MC9BGDcLk2ZE/R 7ugQ== X-Received: by 10.236.177.100 with SMTP id c64mr31033615yhm.30.1397831245157; Fri, 18 Apr 2014 07:27:25 -0700 (PDT) Received: from [192.168.124.105] ([186.188.80.235]) by mx.google.com with ESMTPSA id c66sm53899321yhk.23.2014.04.18.07.27.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 18 Apr 2014 07:27:24 -0700 (PDT) Message-ID: <53513649.2030907@gmail.com> Date: Fri, 18 Apr 2014 09:57:21 -0430 From: Alejandro Acosta User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Philip Homburg References: <534BF803.3090600@viagenie.ca> <535091FB.9010203@gmail.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/pPP2CUJ2PEezJ7jHcPzY-Zy8qSE Cc: homenet@ietf.org Subject: Re: [homenet] Please review the No IPv4 draft 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, 18 Apr 2014 14:27:30 -0000 Hi Philip, El 4/18/2014 3:28 AM, Philip Homburg escribió: > In your letter dated Thu, 17 Apr 2014 22:16:19 -0430 you wrote: >> I like the idea of having the No-IPv4 option for DHCPv6. I don't like >> the idea of having this option in a v4 world; mainly because in mix >> networks where you might have some folks which only speak IPv4, imagine >> a case where this option is sent by a DHCPv4 to a client who do not >> understand v6. Of course, probably the client won't understand the >> option and won't turn off IPv4. There is also the chance that this is a >> modern OS but for some reason IPv6 was disable in the host, yes, it will >> understand the option No-VP6 (sent by a dhcp4). > > As far as I understand, this draft addresses the situation where the network > doesn't offer IPv4 in the first place. You are absolutely right...., thanks. But anyway the scenario I mentioned above can also exists (and for good or bad eventually will happen).. I just wanted to express my position about the option NO-IPv4 in DHCPv4 > > So any IPv4-only host would have no internet connectivity anyhow, whether it > processes the option or not. > > From nobody Fri Apr 18 08:57:03 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 B56B71A03D4 for ; Fri, 18 Apr 2014 08:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 HUn3o-RTlyTM for ; Fri, 18 Apr 2014 08:56:52 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id E30941A0296 for ; Fri, 18 Apr 2014 08:56:52 -0700 (PDT) Received: from [192.168.146.119] (unknown [70.114.139.95]) by toccata.fugue.com (Postfix) with ESMTPSA id 189302380437; Fri, 18 Apr 2014 11:56:47 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: <53511FBC.5060307@viagenie.ca> Date: Fri, 18 Apr 2014 10:56:46 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <534BF803.3090600@viagenie.ca> <87wqes3pms.fsf@toke.dk> <534C214F.6010603@viagenie.ca> <878ur67rx2.fsf@toke.dk> <534D383E.2090602@viagenie.ca> <534D4F40.5050102@viagenie.ca> <534D58E7.2050702@viagenie.ca> <534E7C48.6070001@viagenie.ca> <4C9B747D-451A-456F-BF59-E447583A04E6@fugue.com> <534EAEE6.1060305@thekelleys.org.uk> <534FE41C.50008@viagenie.ca> <53511FBC.5060307@viagenie.ca> To: Simon Perreault X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/TrUwSSBah5KUD8UA59RF0DIwOwY Cc: Erik Kline , "homenet@ietf.org" , Lorenzo Colitti Subject: Re: [homenet] Please review the No IPv4 draft 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, 18 Apr 2014 15:56:59 -0000 On Apr 18, 2014, at 7:51 AM, Simon Perreault = wrote: > Got it. So, summarizing, for Android, DHCPv4 and DHCPv6 options would > likely not be problematic, but an RA option likely would. This is weird, though. How does a DHCPv6 client know to attempt = configuration, if it doesn't see RAs? I just hacked around this on my = router at home in order to get Comcast IPv6 working, but that seems = broken. From nobody Fri Apr 18 10:15:26 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 1F4341A041E for ; Fri, 18 Apr 2014 10:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 V59SpQjkXk-d for ; Fri, 18 Apr 2014 10:15:16 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id A7CD41A02C0 for ; Fri, 18 Apr 2014 10:15:16 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:349d:fe5f:bc57:89]) by jazz.viagenie.ca (Postfix) with ESMTPSA id D17FA4038F; Fri, 18 Apr 2014 13:15:11 -0400 (EDT) Message-ID: <53515D9F.5010207@viagenie.ca> Date: Fri, 18 Apr 2014 13:15:11 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Ted Lemon References: <534BF803.3090600@viagenie.ca> <87wqes3pms.fsf@toke.dk> <534C214F.6010603@viagenie.ca> <878ur67rx2.fsf@toke.dk> <534D383E.2090602@viagenie.ca> <534D4F40.5050102@viagenie.ca> <534D58E7.2050702@viagenie.ca> <534E7C48.6070001@viagenie.ca> <4C9B747D-451A-456F-BF59-E447583A04E6@fugue.com> <534EAEE6.1060305@thekelleys.org.uk> <534FE41C.50008@viagenie.ca> <53511FBC.5060307@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/PqCK3DchZG5HmjuiRFvaKfgRDis Cc: Erik Kline , "homenet@ietf.org" , Lorenzo Colitti Subject: Re: [homenet] Please review the No IPv4 draft 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, 18 Apr 2014 17:15:24 -0000 Le 2014-04-18 11:56, Ted Lemon a écrit : > On Apr 18, 2014, at 7:51 AM, Simon Perreault wrote: >> Got it. So, summarizing, for Android, DHCPv4 and DHCPv6 options would >> likely not be problematic, but an RA option likely would. > > This is weird, though. How does a DHCPv6 client know to attempt configuration, if it doesn't see RAs? I just hacked around this on my router at home in order to get Comcast IPv6 working, but that seems broken. I don't know how Android does it, but any DHCPv6 client is free to unilaterally attempt configuration. It doesn't need to wait for an RA to tell it to do so. RAs are just a hint. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Fri Apr 18 10:23: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 88D711A0444 for ; Fri, 18 Apr 2014 10:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 jP63R4npWNQ6 for ; Fri, 18 Apr 2014 10:23:38 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id BF1EC1A02BA for ; Fri, 18 Apr 2014 10:23:33 -0700 (PDT) Received: from [192.168.146.119] (unknown [70.114.139.95]) by toccata.fugue.com (Postfix) with ESMTPSA id 02EE82380437; Fri, 18 Apr 2014 13:23:28 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: <53515D9F.5010207@viagenie.ca> Date: Fri, 18 Apr 2014 12:23:27 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <534BF803.3090600@viagenie.ca> <87wqes3pms.fsf@toke.dk> <534C214F.6010603@viagenie.ca> <878ur67rx2.fsf@toke.dk> <534D383E.2090602@viagenie.ca> <534D4F40.5050102@viagenie.ca> <534D58E7.2050702@viagenie.ca> <534E7C48.6070001@viagenie.ca> <4C9B747D-451A-456F-BF59-E447583A04E6@fugue.com> <534EAEE6.1060305@thekelleys.org.uk> <534FE41C.50008@viagenie.ca> <53511FBC.5060307@viagenie.ca> <53515D9F.5010207@viagenie.ca> To: Simon Perreault X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/eUebDkE8yndKagOo9ZeR49A-KCo Cc: Erik Kline , "homenet@ietf.org" , Lorenzo Colitti Subject: Re: [homenet] Please review the No IPv4 draft 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, 18 Apr 2014 17:23:42 -0000 On Apr 18, 2014, at 12:15 PM, Simon Perreault = wrote: > I don't know how Android does it, but any DHCPv6 client is free to > unilaterally attempt configuration. It doesn't need to wait for an RA = to > tell it to do so. RAs are just a hint. Sure, but then it's completely disconnected from the comings and goings = of router advertisements on the wire. And, indeed, from the comings = and goings of the wire itself. From nobody Fri Apr 18 19:35: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 E2CD61A0235 for ; Fri, 18 Apr 2014 19:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 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.272, 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 sbQL6-sRJbzB for ; Fri, 18 Apr 2014 19:35:06 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 193061A021E for ; Fri, 18 Apr 2014 19:35:06 -0700 (PDT) Received: by mail-ie0-f179.google.com with SMTP id lx4so2191815iec.38 for ; Fri, 18 Apr 2014 19:35:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wccHAyswjXPSN7JCnvW0Fn20YMRh9B0ASBLGynVP8t8=; b=TbnmbvS1erm3PRx//oeDR9/q9kx2k+QIYHEv4m8WwJ9+aQPGZ9BWjAbfhAlFPGydqP vuVVALhoHD2d2MPyXylT/Hzt0J4CVFluLn2x1fZ4SRB7YZZX30Guzcmvrrwl+8HvHzJ+ 6oC2HTHvAPuioU3rx/eiU/6aTO0XZsqIprvzdiPXcHGpHNFqcXpgdwTBnGv14PlNoHCd 5OaWmj0WjxGn0fcqg/xwDZBg4gweeaN+H0+TYpzmFev+OKeKvkc9j/wkGwSwaxvqYxiT cXTU7G3+SyxxV7gZpHS35NXWlpgxLLjQpcZHcI0HZ9gIK3t50OqVTHGjteIi38j0IE6V Pz1A== 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:date :message-id:subject:from:to:cc:content-type; bh=wccHAyswjXPSN7JCnvW0Fn20YMRh9B0ASBLGynVP8t8=; b=GP/+lOLOrWpWQYFFYLqyHs3//7Phy2+/Bz0vSfp8L7gEPI6Ra7WhBFh5KhBujZkIcp +3dwcphxuscAf/vAIzSBknS79YD1ioplAHZDSEqWHf+mXTR9qod0d2je/mjWOr+T1QN5 fF22Hv3t4KYlbSiZfuyTeIa+fo+JMRZzsgP+AGV+3pr//RxNzXXhNlZiscNjOKt7csPY A3MRRi2uW7/Ow1SNLu9HCMPHVXxSBkZZ6BQmoj4r67r8S4m23nXDsA2ARen/goUPk0cf jly4gBHiX3xFasb7fgYtz2Xd+J4SMUJrOmGOLuWRGT5pu5I6Sd+65lMJrG6lNm6SqeF+ +NCA== X-Gm-Message-State: ALoCoQmorkVsjv9K/FfErjDgcLoha40cMkEtHYNo6os+ZyhDtJgr+Dt4/oCX48yGxapt7mcAaM04UOaY7kN/tXP9rKomThOQdRitLMLT1YeSssdp+Amxe4ZykUlDtTCnlCWTKXy6KvP+faNQAYBvyDQDBM8mrCYq6x2Lv4MrpcZ2Tr0GjpZ8syVEUsixO++q6zE/oeIUX5Cj MIME-Version: 1.0 X-Received: by 10.50.136.229 with SMTP id qd5mr7775140igb.48.1397874901825; Fri, 18 Apr 2014 19:35:01 -0700 (PDT) Received: by 10.64.106.225 with HTTP; Fri, 18 Apr 2014 19:35:00 -0700 (PDT) Received: by 10.64.106.225 with HTTP; Fri, 18 Apr 2014 19:35:00 -0700 (PDT) In-Reply-To: References: <534BF803.3090600@viagenie.ca> <87wqes3pms.fsf@toke.dk> <534C214F.6010603@viagenie.ca> <878ur67rx2.fsf@toke.dk> <534D383E.2090602@viagenie.ca> <534D4F40.5050102@viagenie.ca> <534D58E7.2050702@viagenie.ca> <534E7C48.6070001@viagenie.ca> <4C9B747D-451A-456F-BF59-E447583A04E6@fugue.com> <534EAEE6.1060305@thekelleys.org.uk> <534FE41C.50008@viagenie.ca> <53511FBC.5060307@viagenie.ca> <53515D9F.5010207@viagenie.ca> Date: Sat, 19 Apr 2014 11:35:00 +0900 Message-ID: From: Lorenzo Colitti To: Ted Lemon Content-Type: multipart/alternative; boundary=089e0129463ef6e9d004f75c1c18 Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/9q9oySEiV3X4esTPXSyoH_ggzS0 Cc: Erik Kline , "homenet@ietf.org" Subject: Re: [homenet] Please review the No IPv4 draft 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, 19 Apr 2014 02:35:11 -0000 --089e0129463ef6e9d004f75c1c18 Content-Type: text/plain; charset=UTF-8 On 19 Apr 2014 02:23, "Ted Lemon" wrote: > > On Apr 18, 2014, at 12:15 PM, Simon Perreault wrote: > > I don't know how Android does it, but any DHCPv6 client is free to > > unilaterally attempt configuration. It doesn't need to wait for an RA to > > tell it to do so. RAs are just a hint. > > Sure, but then it's completely disconnected from the comings and goings of router advertisements on the wire. And, indeed, from the comings and goings of the wire itself. One of the many reasons DHCPv6 is not a good protocol to configure addressing and routing. --089e0129463ef6e9d004f75c1c18 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 19 Apr 2014 02:23, "Ted Lemon" <mellon@fugue.com> wrote:
>
> On Apr 18, 2014, at 12:15 PM, Simon Perreault <simon.perreault@viagenie.ca> wrote:
> > I don't know how Android does it, but any DHCPv6 client is fr= ee to
> > unilaterally attempt configuration. It doesn't need to wait f= or an RA to
> > tell it to do so. RAs are just a hint.
>
> Sure, but then it's completely disconnected from the comings and g= oings of router advertisements on the wire. =C2=A0 And, indeed, from the co= mings and goings of the wire itself.

One of the many reasons DHCPv6 is not a good=C2=A0 protocol = to configure addressing and routing.

--089e0129463ef6e9d004f75c1c18-- From nobody Sat Apr 19 02:32: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 87E601A017F for ; Sat, 19 Apr 2014 02:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2] 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 MOopauwT3iEj for ; Sat, 19 Apr 2014 02:32:47 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id D4E8D1A0194 for ; Sat, 19 Apr 2014 02:32:46 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #76) id m1WbRdY-0000BxC; Sat, 19 Apr 2014 11:32:40 +0200 Message-Id: To: Alejandro Acosta From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <534BF803.3090600@viagenie.ca> <535091FB.9010203@gmail.com> <53513649.2030907@gmail.com> In-reply-to: Your message of "Fri, 18 Apr 2014 09:57:21 -0430 ." <53513649.2030907@gmail.com> Date: Sat, 19 Apr 2014 11:32:38 +0200 Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/8w3qcaJDfe-2-ZJRvj0eAmJ1g0Y Cc: homenet@ietf.org Subject: Re: [homenet] Please review the No IPv4 draft 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, 19 Apr 2014 09:32:49 -0000 In your letter dated Fri, 18 Apr 2014 09:57:21 -0430 you wrote: >You are absolutely right...., thanks. >But anyway the scenario I mentioned above can also exists (and for good >or bad eventually will happen).. I just wanted to express my position >about the option NO-IPv4 in DHCPv4 I'd say that if you want to play games and turn off IPv4 for some hosts and not for others then you are better off putting the option in DHCPv4. Putting the option in RA makes it all or nothing. You either tell all IPv6 hosts to turn off IPv4 or none. Putting the option in DHCPv6 requires careful coordination between the DHCPv6 and DHCPv4 configs. The DHCPv6 server would have to send the option in the IPv6 config and the DHCPv4 server has to refrain from sending an offer. This can be tricky if the DHCPv4 and DHCPv6 device ids are different. In contrast, putting the option in DHCPv4 only requires setting a flag in the DHCPv4 config that particular host should not get IPv4. If we require the DHCPv4 client to include the option in the DISCOVER then it is also easy to tell old and new hosts apart. From nobody Mon Apr 21 11:37: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 B44E01A0246 for ; Mon, 21 Apr 2014 11:37:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-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 YXHBSK-EWaWO for ; Mon, 21 Apr 2014 11:37:16 -0700 (PDT) Received: from atl4mhob19.myregisteredsite.com (atl4mhob19.myregisteredsite.com [209.17.115.112]) by ietfa.amsl.com (Postfix) with ESMTP id CA71A1A023E for ; Mon, 21 Apr 2014 11:37:16 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.211]) by atl4mhob19.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s3LIb3at021815 for ; Mon, 21 Apr 2014 14:37:03 -0400 Received: (qmail 4169 invoked by uid 0); 21 Apr 2014 18:36:51 -0000 X-TCPREMOTEIP: 204.235.115.167 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?10.71.36.63?) (lee@asgard.org@204.235.115.167) by 0 with ESMTPA; 21 Apr 2014 18:36:50 -0000 User-Agent: Microsoft-MacOutlook/14.3.9.131030 Date: Mon, 21 Apr 2014 14:36:48 -0400 From: Lee Howard To: Ted Lemon , Simon Perreault Message-ID: Thread-Topic: [homenet] Please review the No IPv4 draft References: <534BF803.3090600@viagenie.ca> <87wqes3pms.fsf@toke.dk> <534C214F.6010603@viagenie.ca> <878ur67rx2.fsf@toke.dk> <534D383E.2090602@viagenie.ca> <534D4F40.5050102@viagenie.ca> <534D58E7.2050702@viagenie.ca> <534E7C48.6070001@viagenie.ca> <4C9B747D-451A-456F-BF59-E447583A04E6@fugue.com> <534EAEE6.1060305@thekelleys.org.uk> <534FE41C.50008@viagenie.ca> <53511FBC.5060307@viagenie.ca> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/Jrv56zHZXEmDIYXPMhxa_Q6DUEk Cc: Erik Kline , "homenet@ietf.org" , Lorenzo Colitti Subject: Re: [homenet] Please review the No IPv4 draft 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, 21 Apr 2014 18:37:22 -0000 On 4/18/14 11:56 AM, "Ted Lemon" wrote: >On Apr 18, 2014, at 7:51 AM, Simon Perreault > wrote: >> Got it. So, summarizing, for Android, DHCPv4 and DHCPv6 options would >> likely not be problematic, but an RA option likely would. > >This is weird, though. How does a DHCPv6 client know to attempt >configuration, if it doesn't see RAs? I just hacked around this on my >router at home in order to get Comcast IPv6 working, but that seems >broken. Depends on OS. At least one version of Windows apparently optimistically sends DHCPv6 SOLICIT regardless of RAs. Lee From nobody Mon Apr 21 13:44: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 ED0F81A02AC for ; Mon, 21 Apr 2014 13:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 a25UWDWiwTNB for ; Mon, 21 Apr 2014 13:43:53 -0700 (PDT) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id C93A11A02A3 for ; Mon, 21 Apr 2014 13:43:53 -0700 (PDT) Received: by mail-pd0-f177.google.com with SMTP id y10so4022209pdj.22 for ; Mon, 21 Apr 2014 13:43:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=/6xR3aDmd2nBNw7hpcjwPxj0DqSUsnjt2g9k7bE2r8s=; b=DNkGwrvGWCAin9ORipLBuZd15si8OslxrurRxs2YKxYcd9NpM4Yz3vjQ63uKwmbT0J 81ywEbmp/VTC1Z2hzRvfG9bwgNWRkEt5wgtl0z1NqeXfuom041uI/v+wF4hXSQqiWCBP 4c3J51uzsYM+RByOzTg9SxxPydgo/mKHs4giyRsIe1RVn3FWjxhno+xhQKgN794iY3XF b4cG54GvdfHdChLuUVGxIN7LsRd0Nq1Aj87el0h7gxC7WR7vwSIPZh5WjPxz2cWHWUo5 hPYiQ2uETWFGc5F7h53P3vgIDrSUAsnxrWAX+W6Ym1Twx6hhdeTX/cLGVorgGKBVKULp EjCw== X-Received: by 10.66.164.70 with SMTP id yo6mr40261662pab.85.1398113025203; Mon, 21 Apr 2014 13:43:45 -0700 (PDT) Received: from [192.168.178.20] (240.199.69.111.dynamic.snap.net.nz. [111.69.199.240]) by mx.google.com with ESMTPSA id vf7sm80073746pbc.5.2014.04.21.13.43.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 21 Apr 2014 13:43:44 -0700 (PDT) Message-ID: <535582FE.5010608@gmail.com> Date: Tue, 22 Apr 2014 08:43:42 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Lee Howard References: <534BF803.3090600@viagenie.ca> <87wqes3pms.fsf@toke.dk> <534C214F.6010603@viagenie.ca> <878ur67rx2.fsf@toke.dk> <534D383E.2090602@viagenie.ca> <534D4F40.5050102@viagenie.ca> <534D58E7.2050702@viagenie.ca> <534E7C48.6070001@viagenie.ca> <4C9B747D-451A-456F-BF59-E447583A04E6@fugue.com> <534EAEE6.1060305@thekelleys.org.uk> <534FE41C.50008@viagenie.ca> <53511FBC.5060307@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/LIOUQa4jMg09UzDRzDfhJCWzG44 Cc: "homenet@ietf.org" , Lorenzo Colitti , Ted Lemon , Erik Kline Subject: Re: [homenet] Please review the No IPv4 draft 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, 21 Apr 2014 20:43:58 -0000 On 22/04/2014 06:36, Lee Howard wrote: > > On 4/18/14 11:56 AM, "Ted Lemon" wrote: > >> On Apr 18, 2014, at 7:51 AM, Simon Perreault >> wrote: >>> Got it. So, summarizing, for Android, DHCPv4 and DHCPv6 options would >>> likely not be problematic, but an RA option likely would. >> This is weird, though. How does a DHCPv6 client know to attempt >> configuration, if it doesn't see RAs? I just hacked around this on my >> router at home in order to get Comcast IPv6 working, but that seems >> broken. > > Depends on OS. At least one version of Windows apparently optimistically > sends DHCPv6 SOLICIT regardless of RAs. Yep. That is neither required nor forbidden by the standards, so YMMV. http://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem-00 Brian From nobody Tue Apr 22 01:20:37 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 E77F91A0151; Tue, 22 Apr 2014 01:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 YhRIc7BBXXbj; Tue, 22 Apr 2014 01:20:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 05E711A013D; Tue, 22 Apr 2014 01:20:30 -0700 (PDT) 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.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140422082030.21606.87752.idtracker@ietfa.amsl.com> Date: Tue, 22 Apr 2014 01:20:30 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/4rxG746he9p-EtqOZ0qQqqjIjio Cc: homenet@ietf.org Subject: [homenet] I-D Action: draft-ietf-homenet-hncp-00.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: Tue, 22 Apr 2014 08:20:33 -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 : Home Networking Control Protocol Authors : Markus Stenberg Steven Barth Filename : draft-ietf-homenet-hncp-00.txt Pages : 27 Date : 2014-04-15 Abstract: This document describes the HomeNet Control Protocol (HNCP), a minimalist state synchronization protocol for Homenet routers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-homenet-hncp/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-homenet-hncp-00 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 Tue Apr 22 08:02: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 47D051A0141 for ; Fri, 18 Apr 2014 19:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 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, RP_MATCHES_RCVD=-0.272, 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 hu4kABoEwEiD for ; Fri, 18 Apr 2014 19:14:31 -0700 (PDT) Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 388071A003A for ; Fri, 18 Apr 2014 19:14:31 -0700 (PDT) Received: by mail-qc0-f173.google.com with SMTP id r5so2227247qcx.4 for ; Fri, 18 Apr 2014 19:14:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=D6qgWit4/rlb5FXPzazcspnC9XT3/w4wMIdoTmDj+as=; b=gMDxJ0xM001CFLA4/h/krwmzw9SKR9p75eZbPljTH5eB2mfsfUtkE4GEsYfKj8TB03 0dRZYxrwT5EyyjqmAJd045ckQa+A5oj+RWGqfoTbRgf+mbzadqXivC6/rI/dt2n5nHU0 4FgiTaaXC867M9d14fuh+/I/fFqFnQVQY+lrVA0qzp4yknt/rhKHsV/E++Gir75fOtCj s3UQbQEehlwLq1ZlA8rABmmnaxZ4hL9Omwq22Cf9dWzgbAUXBXeiMMnlC9Zq9HMQVn1Z dklbuKG8plzJtEc7kkbFVodz2i3vyUjtZ1llUMQmkjFqFDklP07YUWF+8PZaoMpKKDN1 OoHg== 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=D6qgWit4/rlb5FXPzazcspnC9XT3/w4wMIdoTmDj+as=; b=CTBP3G9ViPKbPeeGVrWxJzfI7xyoN73RkUNZVZzVhIdRXwkHxcHk3VPTi6HsVO/s2k LK0fUWxbmCLzRuyONw5IJVsPaCX4SKFWevQ1u6++P3uK6YaW/hOZCIjL9Hg3EoiDmoX+ Y7dKFbP3W2GZc2+Lt/f8JE1spPBkX/csmWc75QP8QagVdBfFlMsI1kJErOoh6BjvAvt2 6m/KvnehhthgA5v6hvHDQGM4j1nP+SRgtsV/zelZum5qRUgAzYs//KNUz/RzV8I0Wmq0 yZv9n3ltX9ryqjc4Hl6D8B8moSu7IY6JWQCuG/kjg2FfVppMwdnK9LcAdIt4NxTdDl8q uWOQ== X-Gm-Message-State: ALoCoQnfOdp7rQyc6F9kbYZFbyk3johtqqWHMq621ryGP48DRMdJOu+HGasCa1C4W/Nh3uNmHNRbv7O4/K+eLIrofENhYqJp5Kg6Jzj8w0C7/LowPwc7ShTYcwBspRPmY3ZNP6AKQRk3+HoVGrJUDAkSOQSUM5e1T13b8P1pqHCMLpcVT42TTLTX3Xktxy9+MxNfbX8UUEXO X-Received: by 10.224.165.139 with SMTP id i11mr33606qay.94.1397873666902; Fri, 18 Apr 2014 19:14:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.28.195 with HTTP; Fri, 18 Apr 2014 19:14:06 -0700 (PDT) In-Reply-To: References: <534BF803.3090600@viagenie.ca> <87wqes3pms.fsf@toke.dk> <534C214F.6010603@viagenie.ca> <878ur67rx2.fsf@toke.dk> <534D383E.2090602@viagenie.ca> <534D4F40.5050102@viagenie.ca> <534D58E7.2050702@viagenie.ca> <534E7C48.6070001@viagenie.ca> <4C9B747D-451A-456F-BF59-E447583A04E6@fugue.com> <534EAEE6.1060305@thekelleys.org.uk> <534FE41C.50008@viagenie.ca> <53511FBC.5060307@viagenie.ca> <53515D9F.5010207@viagenie.ca> From: Erik Kline Date: Sat, 19 Apr 2014 11:14:06 +0900 Message-ID: To: Ted Lemon Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/_Kre5vNPZv-Pqn75aRMJ4wntsAQ X-Mailman-Approved-At: Tue, 22 Apr 2014 08:02:53 -0700 Cc: "homenet@ietf.org" , Lorenzo Colitti Subject: Re: [homenet] Please review the No IPv4 draft 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, 19 Apr 2014 02:14:35 -0000 On 19 April 2014 02:23, Ted Lemon wrote: > On Apr 18, 2014, at 12:15 PM, Simon Perreault wrote: >> I don't know how Android does it, but any DHCPv6 client is free to >> unilaterally attempt configuration. It doesn't need to wait for an RA to >> tell it to do so. RAs are just a hint. > > Sure, but then it's completely disconnected from the comings and goings of router advertisements on the wire. And, indeed, from the comings and goings of the wire itself. Make no mistake though, on some access networks what they need to see is the client's RS, so it can get injected with Suresh's line id and pass up to the BNG to craft the correct customer RA in response*. Randomly doing DHCPv6 before even doing RS's is not guaranteed to get you anything in these networks. Always doing DHCPv6 regardless smells like "IPv4 think" to me. * the RS resiliency work is aimed to make this as reliable as possible. From nobody Tue Apr 22 08:07:47 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 43EB41A0552 for ; Tue, 22 Apr 2014 08:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 kdbxOAfdN3sK for ; Tue, 22 Apr 2014 08:07:44 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id D18FF1A063E for ; Tue, 22 Apr 2014 08:07:41 -0700 (PDT) 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 A2D282380424; Tue, 22 Apr 2014 11:07:35 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: Date: Tue, 22 Apr 2014 11:07:32 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <534BF803.3090600@viagenie.ca> <87wqes3pms.fsf@toke.dk> <534C214F.6010603@viagenie.ca> <878ur67rx2.fsf@toke.dk> <534D383E.2090602@viagenie.ca> <534D4F40.5050102@viagenie.ca> <534D58E7.2050702@viagenie.ca> <534E7C48.6070001@viagenie.ca> <4C9B747D-451A-456F-BF59-E447583A04E6@fugue.com> <534EAEE6.1060305@thekelleys.org.uk> <534FE41C.50008@viagenie.ca> <53511FBC.5060307@viagenie.ca> <53515D9F.5010207@viagenie.ca> To: Erik Kline X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/ap79k--n0rx5cWUYC_Md7hxP15s Cc: "homenet@ietf.org" , Lorenzo Colitti Subject: Re: [homenet] Please review the No IPv4 draft 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, 22 Apr 2014 15:07:46 -0000 On Apr 18, 2014, at 10:14 PM, Erik Kline wrote: > Make no mistake though, on some access networks what they need to see > is the client's RS, so it can get injected with Suresh's line id and > pass up to the BNG to craft the correct customer RA in response*. > Randomly doing DHCPv6 before even doing RS's is not guaranteed to get > you anything in these networks. Right. ISTM that in some cases sending DHCPv6 messages before getting = a response to an RS might be a minor speedup, because you can do both = processes in parallel, but you aren't actually going to have = connectivity until you get the RA anyway. And if the state machines = aren't interdependent, you're going to see all sorts of bad behavior, = which I am fairly sure the Microsoft implementation does not exhibit. So the fact that the Microsoft state machine has this small speed hack = in it does not mean that the state machines are not interdependent. From SRS0=5j7O=Z4=darou.fr=pierre.pfister@bounces.m4x.org Mon Apr 28 06:10: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 BE4E61A09E8 for ; Mon, 28 Apr 2014 06:10:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 UQrbZpBpkz8K for ; Mon, 28 Apr 2014 06:10:17 -0700 (PDT) Received: from mx1.polytechnique.org (mx1.polytechnique.org [129.104.30.34]) by ietfa.amsl.com (Postfix) with ESMTP id 2DFD61A09F8 for ; Mon, 28 Apr 2014 06:10:16 -0700 (PDT) Received: from [10.148.10.37] (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 1A8A61408EEE4 for ; Mon, 28 Apr 2014 15:10:13 +0200 (CEST) From: Pierre Pfister Content-Type: multipart/alternative; boundary="Apple-Mail=_A7CDF927-76A3-495F-A6FB-0F8025260200" Message-Id: Date: Mon, 28 Apr 2014 15:10:12 +0200 To: "homenet@ietf.org Group" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) X-AV-Checked: ClamAV using ClamSMTP at svoboda.polytechnique.org (Mon Apr 28 15:10:14 2014 +0200 (CEST)) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/CXH7LyZyUZz1PQa276i879xrw4g Subject: [homenet] Homenet multicast support 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, 28 Apr 2014 13:11:22 -0000 --Apple-Mail=_A7CDF927-76A3-495F-A6FB-0F8025260200 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hello group, I=92m working on the homenet experimental implementation = http://www.homewrt.org/ and have been thinking on multicast support for = homenet. Encountering a few design issues, comments from the working = group could be helpful. This is a short version of my thoughts about the problem. I=92m thinking = about writing a draft about it. But I would like some feedbacks from the = group. 1) Why supporting multicast. I think homenet should support: - Hosts in the home should be able to join a group and receive traffic = from inside the home and from ISPs if they provide traffic for it (and = the scope allows it) - SSM should be supported. - It should work with multi-homing. Do you think these are reasonable requirements ? 2) Scope considerations. A basic home router supports =AB internal =BB and =AB external =BB = interfaces. So for each multicast scope, we should define the default = behavior for each case. Possibly, improved routers may support tunnels = between homes or home administration areas.=20 One possible default behavior could be: - Admin-local: Block from external (optionally block from tunnels and = other home sub-areas) (Might be used to create sub-areas in the home = network). - Site-Local: Block from external (optionally block from tunnels) (Local = to geographically localized area, for connexion between multiple sites = like VPNs between homes, use a bigger scope) - 6, 7 and 8 (Organization Local): Block from external (Organization = Local being the bigger Home-local scope, in case you own multiple homes = for instance, or distant servers connected through VPNs, etc...) - 9 to E (global scope): Accept from internal and external links I think multicast packets originated inside the home must never leave = the home network. Are these definitions reasonable to you ? 3) Using PIM SM. I=92ve been looking at PIM as a solution candidate (If you think another = MRP could be used, please tell ! :-) ). I don=92t consider DM as a = possible solution. SM and BIDIR could be used. SM would work out of the box if there was no issues with multi-homing. = Indeed, border routers have to subscribe to groups on external = interfaces when some host inside the home has interest for the group. So = border routers needs to be aware of the subscriptions inner hosts made. So either: - Only a single ISP sends traffic from the outside for each group. In = which case we can use a group-to-rp mapping where every border router is = a RP for its own group. That is supported by PIM. We would need = configuration (e.g. DHCP, static) from ISPs to create that mapping. - We want multiple ISPs to be able to send traffic for some group, in = which case a single RP should send subscription control messages to all = border routers in order to control home multicast subscriptions (That = would require modifications to PIM). Another issue comes when using SSM. The path (S, G) subscriptions follow = is dictated by routers=92 routing tables. That works well when the = source is inside the routing domain (the home), or when there is a = single border router (and that router is the RP). When there are = multiple border routers, there are multiple default routes. We need do = decide which border router to use, and that must be consistent. We could = use a group-to-rp mapping as well here. Or a single RP could send = control unicast packets to border routers (like previously). I have a = more precise description of that possibility, but I want to keep that = mail =91=92short=92=92. 4) Using PIM BIDIR. I personally prefer the BIDIR possibility. With a single RP which sends = subscription control messages to border routers (that would require = protocol specs). (*,G) would flow toward the RP and (S,G) would flow = toward the source when it is inside the home, or toward the RP when the = source is outside the home. By default, this architecture would not = support path optimization when the source is outside the home.=20 But: - I imagine future home networks to be organized around high-bandwidth = link(s) (e.g. wired) attached to CPE border routers and less efficient = links (wifi, sensor networks, =85). So in BIDIR, it=92s not a problem = receiving more traffic on the central link, and path optimization would = often not optimize anything. - In general, it could be useful to have a way for ISPs to say =91I do = own these addresses=92. For instance, RA=92s RIOs could be used. In = which case the routes would be injected in the routing protocol, and = (S,G) messages could flow toward the correct home exit. The good news about BIDIR being that it works even when you don=92t = really know how to route (S,G) subscriptions. Which we don=92t in = general when S is outside the home. Does anybody know about some IPv6 BIDIR implementation we could = use/patch ? That would be very helpful !! 5) For autoconf PIM makes use of its own bootstrapping extension. HNCP could be used as = well for the exactly same purpose (election is pretty obvious in HNCP). = An extension would be really easy do define. What do you think ? Thank you for your comments, Pierre --Apple-Mail=_A7CDF927-76A3-495F-A6FB-0F8025260200 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Hello group,

I=92m working on the = homenet experimental implementation http://www.homewrt.org/ and have = been thinking on multicast support for homenet. Encountering a few = design issues, comments from the working group could be = helpful.

This is a short version of my thoughts about = the problem. I=92m thinking about writing a draft about it. But I would = like some feedbacks from the group.


1) Why supporting multicast.

I = think homenet should support:
- = Hosts in the home should be able to join a group and receive traffic = from inside the home and from ISPs if they provide traffic for it (and = the scope allows it)
- SSM should = be supported.
- It should work with = multi-homing.

Do you think these are reasonable = requirements ?



2) Scope = considerations.

A basic home router supports = =AB internal =BB and =AB external =BB interfaces. So = for each multicast scope, we should define the default behavior for each = case.  Possibly, improved routers may support tunnels between homes = or home administration areas. 
One possible default behavior could be:
- Admin-local: Block from external = (optionally block from tunnels and other home sub-areas) (Might be used = to create sub-areas in the home network).
- Site-Local: Block from external (optionally block from tunnels) = (Local to geographically localized area, for connexion between multiple = sites like VPNs between homes, use a bigger scope)
- 6, 7 and 8 (Organization Local): Block from = external (Organization Local being the bigger Home-local scope, in case = you own multiple homes for instance, or distant servers connected = through VPNs, etc...)
- 9 to E = (global scope): Accept from internal and external links

I = think multicast packets originated inside the home must never leave the = home network.

Are these definitions reasonable to you = ?



3) Using PIM SM.

I=92ve been looking at = PIM as a solution candidate (If you think another MRP could be used, = please tell ! :-) ). I don=92t consider DM as a possible solution. SM = and BIDIR could be used.
SM would = work out of the box if there was no issues with multi-homing. Indeed, = border routers have to subscribe to groups on external interfaces when = some host inside the home has interest for the group. So border routers = needs to be aware of the subscriptions inner hosts made.

So = either:
- Only a single ISP sends = traffic from the outside for each group. In which case we can use a = group-to-rp mapping where every border router is a RP for its own group. = That is supported by PIM. We would need configuration (e.g. DHCP, = static) from ISPs to create that mapping.
- We want multiple ISPs to be able to send traffic for some = group, in which case a single RP should send subscription control = messages to all border routers in order to control home multicast = subscriptions (That would require modifications to PIM).

Another issue comes when using SSM. The path (S, G) subscriptions = follow is dictated by routers=92 routing tables. That works well when = the source is inside the routing domain (the home), or when there is a = single border router (and that router is the RP). When there are = multiple border routers, there are multiple default routes. We need do = decide which border router to use, and that must be consistent. We could = use a group-to-rp mapping as well here. Or a single RP could send = control unicast packets to border routers (like previously). I have a = more precise description of that possibility, but I want to keep that = mail =91=92short=92=92.



4) = Using PIM BIDIR.

I personally prefer the BIDIR possibility. = With a single RP which sends subscription control messages to border = routers (that would require protocol specs). (*,G) would flow toward the = RP and (S,G) would flow toward the source when it is inside the home, or = toward the RP when the source is outside the home. By default, this = architecture would not support path optimization when the source is = outside the home. 
But:
- I imagine future home = networks to be organized around high-bandwidth link(s) (e.g. wired) = attached to CPE border routers and less efficient links (wifi, sensor = networks, =85). So in BIDIR, it=92s not a problem receiving more traffic = on the central link, and path optimization would often not optimize = anything.
- In general, it could be = useful to have a way for ISPs to say =91I do own these addresses=92. For = instance, RA=92s RIOs could be used. In which case the routes would be = injected in the routing protocol, and (S,G) messages could flow toward = the correct home exit.

The good news about = BIDIR being that it works even when you don=92t really know how to route = (S,G) subscriptions. Which we don=92t in general when S is outside the = home.

Does anybody know about some IPv6 BIDIR = implementation we could use/patch ? That would be very helpful = !!



5) For autoconf
PIM makes use of its own bootstrapping extension. HNCP could be = used as well for the exactly same purpose (election is pretty obvious in = HNCP). An extension would be really easy do define. What do you think = ?


Thank you for your = comments,

Pierre

= --Apple-Mail=_A7CDF927-76A3-495F-A6FB-0F8025260200-- From nobody Mon Apr 28 12:03: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 303D01A7D82; Mon, 28 Apr 2014 12:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 RiUW-_RQsZJW; Mon, 28 Apr 2014 12:02:55 -0700 (PDT) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id DEFE11A6FB1; Mon, 28 Apr 2014 12:02:54 -0700 (PDT) Received: by mail-pd0-f174.google.com with SMTP id z10so5221185pdj.5 for ; Mon, 28 Apr 2014 12:02:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=mG4OkNkH/pkWZgi9h1bVG9s5XsMoeKt+zvoc5ld1UDo=; b=gTE0gFp+a6olmyYUxHRFLXGkFsxZ0dfqQYZrl1Qm60ozUMFaDAQ2O2oEV6XRVr2LKv dPlYWL9KA8PKxF/Eg+3NYo6f+kiOBVhWpoY+Te5ybk9pTUuyM2atNMzYjtFzGlT26AWg BfO1w5sVpZtDlsyDjkJUs45L0w5FD9An9ktIzEQuLyoTuDN9yisZZsa9DY3OFnzmyjAo kL3a7qpy7CQItOnzUGgkFE8BTcZTfBPiPchldhxvdIDnjZiDUfiwmQLSo/37I3EHZaQl jLrvUo/KSrq/WFL/vDv05b+8eYiJL+sDJIFuxqgXky2vKN0gZ873AXITv4aQbL7RnD5z Vs8A== X-Received: by 10.68.202.230 with SMTP id kl6mr27449542pbc.55.1398711773168; Mon, 28 Apr 2014 12:02:53 -0700 (PDT) Received: from [192.168.2.225] (c-67-188-1-12.hsd1.ca.comcast.net. [67.188.1.12]) by mx.google.com with ESMTPSA id cz3sm36679464pbc.9.2014.04.28.12.02.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Apr 2014 12:02:52 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_1DE104C3-B613-45EC-8167-D7C987BB124A" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Douglas Otis In-Reply-To: Date: Mon, 28 Apr 2014 12:02:52 -0700 Message-Id: References: To: Pierre Pfister X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/WbAm3QYpPkGLwTeIvcnjFGa-0eg Cc: "homenet@ietf.org Group" , dnssd@ietf.org Subject: Re: [homenet] Homenet multicast support 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, 28 Apr 2014 19:02:59 -0000 --Apple-Mail=_1DE104C3-B613-45EC-8167-D7C987BB124A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Apr 28, 2014, at 6:10 AM, Pierre Pfister = wrote: > Hello group, >=20 > I=92m working on the homenet experimental implementation = http://www.homewrt.org/ and have been thinking on multicast support for = homenet. Encountering a few design issues, comments from the working = group could be helpful. >=20 > This is a short version of my thoughts about the problem. I=92m = thinking about writing a draft about it. But I would like some feedbacks = from the group. >=20 >=20 > 1) Why supporting multicast. >=20 > I think homenet should support: > - Hosts in the home should be able to join a group and receive traffic = from inside the home and from ISPs if they provide traffic for it (and = the scope allows it) > - SSM should be supported. > - It should work with multi-homing. >=20 > Do you think these are reasonable requirements ? >=20 >=20 > 2) Scope considerations. >=20 > A basic home router supports =AB internal =BB and =AB external =BB = interfaces. So for each multicast scope, we should define the default = behavior for each case. Possibly, improved routers may support tunnels = between homes or home administration areas.=20 > One possible default behavior could be: > - Admin-local: Block from external (optionally block from tunnels and = other home sub-areas) (Might be used to create sub-areas in the home = network). > - Site-Local: Block from external (optionally block from tunnels) = (Local to geographically localized area, for connexion between multiple = sites like VPNs between homes, use a bigger scope) > - 6, 7 and 8 (Organization Local): Block from external (Organization = Local being the bigger Home-local scope, in case you own multiple homes = for instance, or distant servers connected through VPNs, etc...) > - 9 to E (global scope): Accept from internal and external links >=20 > I think multicast packets originated inside the home must never leave = the home network. >=20 > Are these definitions reasonable to you ? >=20 >=20 > 3) Using PIM SM. >=20 > I=92ve been looking at PIM as a solution candidate (If you think = another MRP could be used, please tell ! :-) ). I don=92t consider DM as = a possible solution. SM and BIDIR could be used. > SM would work out of the box if there was no issues with multi-homing. = Indeed, border routers have to subscribe to groups on external = interfaces when some host inside the home has interest for the group. So = border routers needs to be aware of the subscriptions inner hosts made. >=20 > So either: > - Only a single ISP sends traffic from the outside for each group. In = which case we can use a group-to-rp mapping where every border router is = a RP for its own group. That is supported by PIM. We would need = configuration (e.g. DHCP, static) from ISPs to create that mapping. > - We want multiple ISPs to be able to send traffic for some group, in = which case a single RP should send subscription control messages to all = border routers in order to control home multicast subscriptions (That = would require modifications to PIM). >=20 > Another issue comes when using SSM. The path (S, G) subscriptions = follow is dictated by routers=92 routing tables. That works well when = the source is inside the routing domain (the home), or when there is a = single border router (and that router is the RP). When there are = multiple border routers, there are multiple default routes. We need do = decide which border router to use, and that must be consistent. We could = use a group-to-rp mapping as well here. Or a single RP could send = control unicast packets to border routers (like previously). I have a = more precise description of that possibility, but I want to keep that = mail =91=92short=92=92. >=20 >=20 > 4) Using PIM BIDIR. >=20 > I personally prefer the BIDIR possibility. With a single RP which = sends subscription control messages to border routers (that would = require protocol specs). (*,G) would flow toward the RP and (S,G) would = flow toward the source when it is inside the home, or toward the RP when = the source is outside the home. By default, this architecture would not = support path optimization when the source is outside the home.=20 > But: > - I imagine future home networks to be organized around high-bandwidth = link(s) (e.g. wired) attached to CPE border routers and less efficient = links (wifi, sensor networks, =85). So in BIDIR, it=92s not a problem = receiving more traffic on the central link, and path optimization would = often not optimize anything. > - In general, it could be useful to have a way for ISPs to say =91I do = own these addresses=92. For instance, RA=92s RIOs could be used. In = which case the routes would be injected in the routing protocol, and = (S,G) messages could flow toward the correct home exit. >=20 > The good news about BIDIR being that it works even when you don=92t = really know how to route (S,G) subscriptions. Which we don=92t in = general when S is outside the home. >=20 > Does anybody know about some IPv6 BIDIR implementation we could = use/patch ? That would be very helpful !! >=20 >=20 > 5) For autoconf > PIM makes use of its own bootstrapping extension. HNCP could be used = as well for the exactly same purpose (election is pretty obvious in = HNCP). An extension would be really easy do define. What do you think ? Dear Pierre, Adding service filters to RBridge (now deployed supporting PPP) seems to = represent an alternative having security advantages since it does not = depend on layer 3. Using routable IP addresses means publishing is not = without significant risk. An update to mdns-xlink offers an alternative Security Consideration = section from that of draft-ietf-dnssd-requirements. http://tools.ietf.org/html/draft-otis-dnssd-mdns-xlink-03 As an experiment, a test was made using a new popular brand of an IPv6 = enabled printer. Discovery by name resolution and not by address = probing for the printer allowed Internet access without any logs = created. This is a problem not easily resolved using routable IP = addresses. Regards, Douglas Otis --Apple-Mail=_1DE104C3-B613-45EC-8167-D7C987BB124A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Apr 28, 2014, at 6:10 AM, Pierre = Pfister <pierre.pfister@darou.fr> = wrote:

Hello group,

I=92m working on the = homenet experimental implementation http://www.homewrt.org/ and have = been thinking on multicast support for homenet. Encountering a few = design issues, comments from the working group could be = helpful.

This is a short version of my thoughts about = the problem. I=92m thinking about writing a draft about it. But I would = like some feedbacks from the group.


1) Why supporting multicast.

I = think homenet should support:
- = Hosts in the home should be able to join a group and receive traffic = from inside the home and from ISPs if they provide traffic for it (and = the scope allows it)
- SSM should = be supported.
- It should work with = multi-homing.

Do you think these are reasonable = requirements ?


2) = Scope considerations.

A basic home router = supports =AB internal =BB and =AB external =BB = interfaces. So for each multicast scope, we should define the default = behavior for each case.  Possibly, improved routers may support = tunnels between homes or home administration areas. 
One possible default behavior could = be:
- Admin-local: Block from = external (optionally block from tunnels and other home sub-areas) (Might = be used to create sub-areas in the home network).
- Site-Local: Block from external (optionally = block from tunnels) (Local to geographically localized area, for = connexion between multiple sites like VPNs between homes, use a bigger = scope)
- 6, 7 and 8 (Organization = Local): Block from external (Organization Local being the bigger = Home-local scope, in case you own multiple homes for instance, or = distant servers connected through VPNs, etc...)
- 9 to E (global scope): Accept from internal = and external links

I think multicast packets originated inside = the home must never leave the home network.

Are these definitions = reasonable to you ?


3) = Using PIM SM.

I=92ve been looking at PIM as a solution = candidate (If you think another MRP could be used, please tell ! :-) ). = I don=92t consider DM as a possible solution. SM and BIDIR could be = used.
SM would work out of the box = if there was no issues with multi-homing. Indeed, border routers have to = subscribe to groups on external interfaces when some host inside the = home has interest for the group. So border routers needs to be aware of = the subscriptions inner hosts made.

So either:
- Only a single ISP sends traffic from the = outside for each group. In which case we can use a group-to-rp mapping = where every border router is a RP for its own group. That is supported = by PIM. We would need configuration (e.g. DHCP, static) from ISPs to = create that mapping.
- We want = multiple ISPs to be able to send traffic for some group, in which case a = single RP should send subscription control messages to all border = routers in order to control home multicast subscriptions (That would = require modifications to PIM).

Another issue comes = when using SSM. The path (S, G) subscriptions follow is dictated by = routers=92 routing tables. That works well when the source is inside the = routing domain (the home), or when there is a single border router (and = that router is the RP). When there are multiple border routers, there = are multiple default routes. We need do decide which border router to = use, and that must be consistent. We could use a group-to-rp mapping as = well here. Or a single RP could send control unicast packets to border = routers (like previously). I have a more precise description of that = possibility, but I want to keep that mail =91=92short=92=92.


4) Using PIM = BIDIR.

I personally prefer the BIDIR possibility. = With a single RP which sends subscription control messages to border = routers (that would require protocol specs). (*,G) would flow toward the = RP and (S,G) would flow toward the source when it is inside the home, or = toward the RP when the source is outside the home. By default, this = architecture would not support path optimization when the source is = outside the home. 
But:
- I imagine future home = networks to be organized around high-bandwidth link(s) (e.g. wired) = attached to CPE border routers and less efficient links (wifi, sensor = networks, =85). So in BIDIR, it=92s not a problem receiving more traffic = on the central link, and path optimization would often not optimize = anything.
- In general, it could be = useful to have a way for ISPs to say =91I do own these addresses=92. For = instance, RA=92s RIOs could be used. In which case the routes would be = injected in the routing protocol, and (S,G) messages could flow toward = the correct home exit.

The good news about = BIDIR being that it works even when you don=92t really know how to route = (S,G) subscriptions. Which we don=92t in general when S is outside the = home.

Does anybody know about some IPv6 BIDIR = implementation we could use/patch ? That would be very helpful = !!


5) For = autoconf
PIM makes use of its own = bootstrapping extension. HNCP could be used as well for the exactly same = purpose (election is pretty obvious in HNCP). An extension would be = really easy do define. What do you think = ?

Dear = Pierre,

Adding service filters to RBridge (now = deployed supporting PPP) seems to represent an alternative having = security advantages since it does not depend on layer 3.  Using = routable IP addresses means publishing is not without significant = risk.

An update to mdns-xlink offers an = alternative Security Consideration section from that = of draft-ietf-dnssd-requirements.

As an experiment, a test was made using a new popular brand of an = IPv6 enabled printer.  Discovery by name resolution and not by = address probing for the printer allowed Internet access without any logs = created.  This is a problem not easily resolved using routable IP = addresses.

Regards,
Douglas = Otis

= --Apple-Mail=_1DE104C3-B613-45EC-8167-D7C987BB124A-- From nobody Mon Apr 28 12:14: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 855561A701F for ; Mon, 28 Apr 2014 12:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 ox8jNMq71mcL for ; Mon, 28 Apr 2014 12:14:51 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id BC7781A70E1 for ; Mon, 28 Apr 2014 12:14:50 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id n12so3556582wgh.18 for ; Mon, 28 Apr 2014 12:14:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=QeaNTk/bzAlKHe9GwdyXQAzXj6FbnTyWuMgxlmhddkw=; b=FnSB3Wo19sL8zuUo9inqm44W0vETKimbWXfwpXYdqKqnTx+ALFrEKtfG1SDD9WpMpx xTv4KKnsgr6w1EkwR5CROhvrhR9WuRjPInyDG9fWpMwz8XaazcN+llOQQV0zLYcT9euk LFpd4KgpTuZlW7VW61WMkhqF2PffP4ZXiKZqCdoD6aRYzJKJPhoCZ5QlDsquwQ22gotd OZQLX2QSXWe9OHQiOOZ9Tk5jxusG6NANY1tWJaS+vissJfRdrXTgLPjRGGCH8rtA1bSR ZBf0kjqNPgvvESZ6/fCq2jwjWerGUcVDAE02pODJYjxsrVyYKKiTSqQ/FnGBBzeXHyMD fkXg== MIME-Version: 1.0 X-Received: by 10.194.6.106 with SMTP id z10mr20363654wjz.1.1398712489535; Mon, 28 Apr 2014 12:14:49 -0700 (PDT) Received: by 10.216.207.82 with HTTP; Mon, 28 Apr 2014 12:14:49 -0700 (PDT) In-Reply-To: References: Date: Mon, 28 Apr 2014 12:14:49 -0700 Message-ID: From: Dave Taht To: Pierre Pfister Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/5Bm5HE-cUxC0yhVC-u9D9BuUVbk Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Homenet multicast support 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, 28 Apr 2014 19:14:54 -0000 On Mon, Apr 28, 2014 at 6:10 AM, Pierre Pfister w= rote: > Hello group, > > I=E2=80=99m working on the homenet experimental implementation > http://www.homewrt.org/ and have been thinking on multicast support for > homenet. Encountering a few design issues, comments from the working grou= p > could be helpful. > > This is a short version of my thoughts about the problem. I=E2=80=99m thi= nking about > writing a draft about it. But I would like some feedbacks from the group. > > > 1) Why supporting multicast. > > I think homenet should support: > - Hosts in the home should be able to join a group and receive traffic fr= om > inside the home and from ISPs if they provide traffic for it (and the sco= pe > allows it) > - SSM should be supported. > - It should work with multi-homing. > > Do you think these are reasonable requirements ? Sure. However the only thing that still sort of uses multicast from the wan side is some forms of television. Regrettably the state of pim is very very very undertested and the relevant code for it needs love - pimd (what I ship in cero) is rather flaky, and pim support from things like quagga only existed, if ever, out of tree. I don't listen on the wan address. Things like openwrt compile pim out by default. (It's compiled in in cerowrt, but I'm not aware of any users) > > 2) Scope considerations. > > A basic home router supports =C2=AB internal =C2=BB and =C2=AB external = =C2=BB interfaces. So > for each multicast scope, we should define the default behavior for each > case. Possibly, improved routers may support tunnels between homes or ho= me > administration areas. Multicast is a major headache from a firewalling perspective and in multipl= e other regards. The cerowrt bcp38 implementation filters out list match '240.0.0.0/4' # RFC 5745 and relies on source specific routing to filter out other stuff on ipv6. > One possible default behavior could be: > - Admin-local: Block from external (optionally block from tunnels and oth= er > home sub-areas) (Might be used to create sub-areas in the home network). > - Site-Local: Block from external (optionally block from tunnels) (Local = to > geographically localized area, for connexion between multiple sites like > VPNs between homes, use a bigger scope) > - 6, 7 and 8 (Organization Local): Block from external (Organization Loca= l > being the bigger Home-local scope, in case you own multiple homes for > instance, or distant servers connected through VPNs, etc...) > - 9 to E (global scope): Accept from internal and external links > > I think multicast packets originated inside the home must never leave the > home network. Depends on your form of multicast. If they cannot join a group on the next hop up, they won't go anywhere. > Are these definitions reasonable to you ? > > > > 3) Using PIM SM. > > I=E2=80=99ve been looking at PIM as a solution candidate (If you think an= other MRP > could be used, please tell ! :-) ). I don=E2=80=99t consider DM as a poss= ible > solution. SM and BIDIR could be used. > SM would work out of the box if there was no issues with multi-homing. > Indeed, border routers have to subscribe to groups on external interfaces > when some host inside the home has interest for the group. So border rout= ers > needs to be aware of the subscriptions inner hosts made. > > So either: > - Only a single ISP sends traffic from the outside for each group. In whi= ch > case we can use a group-to-rp mapping where every border router is a RP f= or > its own group. That is supported by PIM. We would need configuration (e.g= . > DHCP, static) from ISPs to create that mapping. > - We want multiple ISPs to be able to send traffic for some group, in whi= ch > case a single RP should send subscription control messages to all border > routers in order to control home multicast subscriptions (That would requ= ire > modifications to PIM). > > Another issue comes when using SSM. The path (S, G) subscriptions follow = is > dictated by routers=E2=80=99 routing tables. That works well when the sou= rce is > inside the routing domain (the home), or when there is a single border > router (and that router is the RP). When there are multiple border router= s, > there are multiple default routes. We need do decide which border router = to > use, and that must be consistent. We could use a group-to-rp mapping as w= ell > here. Or a single RP could send control unicast packets to border routers > (like previously). I have a more precise description of that possibility, > but I want to keep that mail =E2=80=98=E2=80=99short=E2=80=99=E2=80=99. > > > > 4) Using PIM BIDIR. > > I personally prefer the BIDIR possibility. With a single RP which sends > subscription control messages to border routers (that would require proto= col > specs). (*,G) would flow toward the RP and (S,G) would flow toward the > source when it is inside the home, or toward the RP when the source is > outside the home. By default, this architecture would not support path > optimization when the source is outside the home. > But: > - I imagine future home networks to be organized around high-bandwidth > link(s) (e.g. wired) attached to CPE border routers and less efficient li= nks > (wifi, sensor networks, =E2=80=A6). So in BIDIR, it=E2=80=99s not a probl= em receiving more > traffic on the central link, and path optimization would often not optimi= ze > anything. > - In general, it could be useful to have a way for ISPs to say =E2=80=98I= do own > these addresses=E2=80=99. For instance, RA=E2=80=99s RIOs could be used. = In which case the > routes would be injected in the routing protocol, and (S,G) messages coul= d > flow toward the correct home exit. > > The good news about BIDIR being that it works even when you don=E2=80=99t= really > know how to route (S,G) subscriptions. Which we don=E2=80=99t in general = when S is > outside the home. > > Does anybody know about some IPv6 BIDIR implementation we could use/patch= ? > That would be very helpful !! > > > > 5) For autoconf > PIM makes use of its own bootstrapping extension. HNCP could be used as w= ell > for the exactly same purpose (election is pretty obvious in HNCP). An > extension would be really easy do define. What do you think ? > > > Thank you for your comments, > > Pierre > > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > --=20 Dave T=C3=A4ht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_= indecent.article From nobody Tue Apr 29 00:52: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 101D61A0757 for ; Tue, 29 Apr 2014 00:52:09 -0700 (PDT) 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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.651, 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 nYNfDd4_d2r4 for ; Tue, 29 Apr 2014 00:52:07 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id C291A1A0746 for ; Tue, 29 Apr 2014 00:52:06 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 36ECCA5; Tue, 29 Apr 2014 09:52:03 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1398757923; bh=lTEcV/G9edvEKVYP/wFVwt+x11M0uCPImrpd2mkrle0=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=K6uiNlbC8fz/dJ36BDhJ84bkCa4BFmO68870KG/Q938ANQ8UagAu4Yb5QURHDAQxM qXclJMoNe+f3rraR6Kj1kRkYthb5WIp68S8YdncfONlOQiiHXiJ+8jtYsGeg0A0+gZ /gYziYyy0TY6LVWW6Ua9f+ADAdYla697g/QbdNhY= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 2DD7EA3; Tue, 29 Apr 2014 09:52:03 +0200 (CEST) Date: Tue, 29 Apr 2014 09:52:03 +0200 (CEST) From: Mikael Abrahamsson To: Pierre Pfister In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-137064504-1850741414-1398757923=:29282" Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/bpZmibOn7hF3YM6M_WsyYoLtdH8 Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Homenet multicast support 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, 29 Apr 2014 07:52:09 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---137064504-1850741414-1398757923=:29282 Content-Type: TEXT/PLAIN; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8BIT On Mon, 28 Apr 2014, Pierre Pfister wrote: > Hello group, > > I’m working on the homenet experimental implementation http://www.homewrt.org/ and have been thinking on multicast support for homenet. Encountering a few design issues, comments from the working group could be helpful. > > This is a short version of my thoughts about the problem. I’m thinking about writing a draft about it. But I would like some feedbacks from the group. > > > 1) Why supporting multicast. > > I think homenet should support: > - Hosts in the home should be able to join a group and receive traffic from inside the home and from ISPs if they provide traffic for it (and the scope allows it) > - SSM should be supported. > - It should work with multi-homing. > > Do you think these are reasonable requirements ? Absolutely, fully support. > 2) Scope considerations. > > A basic home router supports « internal » and « external » interfaces. So for each multicast scope, we should define the default behavior for each case. Possibly, improved routers may support tunnels between homes or home administration areas. > One possible default behavior could be: > - Admin-local: Block from external (optionally block from tunnels and other home sub-areas) (Might be used to create sub-areas in the home network). > - Site-Local: Block from external (optionally block from tunnels) (Local to geographically localized area, for connexion between multiple sites like VPNs between homes, use a bigger scope) > - 6, 7 and 8 (Organization Local): Block from external (Organization Local being the bigger Home-local scope, in case you own multiple homes for instance, or distant servers connected through VPNs, etc...) > - 9 to E (global scope): Accept from internal and external links > > I think multicast packets originated inside the home must never leave the home network. > > Are these definitions reasonable to you ? I would like to not rule out the home as a multicast sender to the outside. I agree not sending out the packets is good default behavior, but there could be potential use-cases going forward where one would actually like the home to be able to source multicast. > 3) Using PIM SM. > > I’ve been looking at PIM as a solution candidate (If you think another > MRP could be used, please tell ! :-) ). I don’t consider DM as a > possible solution. SM and BIDIR could be used. SM would work out of the > box if there was no issues with multi-homing. Indeed, border routers > have to subscribe to groups on external interfaces when some host inside > the home has interest for the group. So border routers needs to be aware > of the subscriptions inner hosts made. > > So either: - Only a single ISP sends traffic from the outside for each > group. In which case we can use a group-to-rp mapping where every border > router is a RP for its own group. That is supported by PIM. We would > need configuration (e.g. DHCP, static) from ISPs to create that mapping. > - We want multiple ISPs to be able to send traffic for some group, in > which case a single RP should send subscription control messages to all > border routers in order to control home multicast subscriptions (That > would require modifications to PIM). > > Another issue comes when using SSM. The path (S, G) subscriptions follow > is dictated by routers’ routing tables. That works well when the source > is inside the routing domain (the home), or when there is a single > border router (and that router is the RP). When there are multiple > border routers, there are multiple default routes. We need do decide > which border router to use, and that must be consistent. We could use a > group-to-rp mapping as well here. Or a single RP could send control > unicast packets to border routers (like previously). I have a more > precise description of that possibility, but I want to keep that mail > ‘’short’’. You don't write this outright, so just let me ask: You don't propose that the home speaks PIM with the ISP, right? In my view, the world the home would do IGMPv3/MLDv2 join towards the ISP. It would then use PIM-SSM within the home for the multicast routing. If we have to insert a static /128 route towards each S, that might be the price to pay. > 4) Using PIM BIDIR. > > I personally prefer the BIDIR possibility. With a single RP which sends > subscription control messages to border routers (that would require > protocol specs). (*,G) would flow toward the RP and (S,G) would flow > toward the source when it is inside the home, or toward the RP when the > source is outside the home. By default, this architecture would not > support path optimization when the source is outside the home. But: Personally I think that SM should go away, and we should only use PIM-SSM. I'd rather see the S being sent out as service discovery messages and discovered that way, rather than using PIM-SM to discover sources. I now read up on BIDIR (didn't know about it before), and.. hm, well, so your proposal is to only use shared trees within the home and nothing else? Well, it's and idea that should be considered. > 5) For autoconf PIM makes use of its own bootstrapping extension. HNCP > could be used as well for the exactly same purpose (election is pretty > obvious in HNCP). An extension would be really easy do define. What do > you think ? Wouldn't it make sense that the HNCP elected routing would have a PIM priority setting that would elect it to be PIM DR on the LAN as well? -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-1850741414-1398757923=:29282-- From SRS0=ha46=Z5=darou.fr=pierre.pfister@bounces.m4x.org Tue Apr 29 01:11: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 AF6E01A08BC for ; Tue, 29 Apr 2014 01:11:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 1ArnF65WMCC3 for ; Tue, 29 Apr 2014 01:11:10 -0700 (PDT) Received: from mx1.polytechnique.org (mx1.polytechnique.org [129.104.30.34]) by ietfa.amsl.com (Postfix) with ESMTP id 4359E1A08BA for ; Tue, 29 Apr 2014 01:11:01 -0700 (PDT) Received: from [10.148.10.37] (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 1490D1400063B; Tue, 29 Apr 2014 10:10:58 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Pierre Pfister In-Reply-To: Date: Tue, 29 Apr 2014 10:10:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1874) X-AV-Checked: ClamAV using ClamSMTP at svoboda.polytechnique.org (Tue Apr 29 10:10:59 2014 +0200 (CEST)) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/wGmdMSbUpoiVNCxO28Z9JsE9mug Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Homenet multicast support 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, 29 Apr 2014 08:11:34 -0000 Thank you for your comments, Le 29 avr. 2014 =E0 09:52, Mikael Abrahamsson a =E9crit= : > On Mon, 28 Apr 2014, Pierre Pfister wrote: >=20 >> Hello group, >>=20 >> I=92m working on the homenet experimental implementation = http://www.homewrt.org/ and have been thinking on multicast support for = homenet. Encountering a few design issues, comments from the working = group could be helpful. >>=20 >> This is a short version of my thoughts about the problem. I=92m = thinking about writing a draft about it. But I would like some feedbacks = from the group. >>=20 >>=20 >> 1) Why supporting multicast. >>=20 >> I think homenet should support: >> - Hosts in the home should be able to join a group and receive = traffic from inside the home and from ISPs if they provide traffic for = it (and the scope allows it) >> - SSM should be supported. >> - It should work with multi-homing. >>=20 >> Do you think these are reasonable requirements ? >=20 > Absolutely, fully support. >=20 >> 2) Scope considerations. >>=20 >> A basic home router supports =AB internal =BB and =AB external =BB = interfaces. So for each multicast scope, we should define the default = behavior for each case. Possibly, improved routers may support tunnels = between homes or home administration areas. >> One possible default behavior could be: >> - Admin-local: Block from external (optionally block from tunnels and = other home sub-areas) (Might be used to create sub-areas in the home = network). >> - Site-Local: Block from external (optionally block from tunnels) = (Local to geographically localized area, for connexion between multiple = sites like VPNs between homes, use a bigger scope) >> - 6, 7 and 8 (Organization Local): Block from external (Organization = Local being the bigger Home-local scope, in case you own multiple homes = for instance, or distant servers connected through VPNs, etc...) >> - 9 to E (global scope): Accept from internal and external links >>=20 >> I think multicast packets originated inside the home must never leave = the home network. >>=20 >> Are these definitions reasonable to you ? >=20 > I would like to not rule out the home as a multicast sender to the = outside. I agree not sending out the packets is good default behavior, = but there could be potential use-cases going forward where one would = actually like the home to be able to source multicast. Why not I guess. Border routers could be configured manually or with = HNCP to allow some groups to be shared with the outside. >=20 >> 3) Using PIM SM. >>=20 >> I=92ve been looking at PIM as a solution candidate (If you think = another MRP could be used, please tell ! :-) ). I don=92t consider DM as = a possible solution. SM and BIDIR could be used. SM would work out of = the box if there was no issues with multi-homing. Indeed, border routers = have to subscribe to groups on external interfaces when some host inside = the home has interest for the group. So border routers needs to be aware = of the subscriptions inner hosts made. >>=20 >> So either: - Only a single ISP sends traffic from the outside for = each group. In which case we can use a group-to-rp mapping where every = border router is a RP for its own group. That is supported by PIM. We = would need configuration (e.g. DHCP, static) from ISPs to create that = mapping. - We want multiple ISPs to be able to send traffic for some = group, in which case a single RP should send subscription control = messages to all border routers in order to control home multicast = subscriptions (That would require modifications to PIM). >>=20 >> Another issue comes when using SSM. The path (S, G) subscriptions = follow is dictated by routers=92 routing tables. That works well when = the source is inside the routing domain (the home), or when there is a = single border router (and that router is the RP). When there are = multiple border routers, there are multiple default routes. We need do = decide which border router to use, and that must be consistent. We could = use a group-to-rp mapping as well here. Or a single RP could send = control unicast packets to border routers (like previously). I have a = more precise description of that possibility, but I want to keep that = mail =91=92short=92=92. >=20 > You don't write this outright, so just let me ask: You don't propose = that the home speaks PIM with the ISP, right? In my view, the world the = home would do IGMPv3/MLDv2 join towards the ISP. It would then use = PIM-SSM within the home for the multicast routing. If we have to insert = a static /128 route towards each S, that might be the price to pay. Of course ! The problem would be quite easier if home and ISP could = speak PIM, but the goal here is to make border routers proxy PIM = subscriptions toward the ISP using IGMPv3/MLDv2 indeed.=20 >=20 >> 4) Using PIM BIDIR. >>=20 >> I personally prefer the BIDIR possibility. With a single RP which = sends subscription control messages to border routers (that would = require protocol specs). (*,G) would flow toward the RP and (S,G) would = flow toward the source when it is inside the home, or toward the RP when = the source is outside the home. By default, this architecture would not = support path optimization when the source is outside the home. But: >=20 > Personally I think that SM should go away, and we should only use = PIM-SSM. I'd rather see the S being sent out as service discovery = messages and discovered that way, rather than using PIM-SM to discover = sources. I now read up on BIDIR (didn't know about it before), and.. hm, = well, so your proposal is to only use shared trees within the home and = nothing else? Well, it's and idea that should be considered. Using service discovery makes sense in order to discover service = sources. But in a dense sources situation, wildcard subscription (*,G) = could still be useful. I think the hard part is SSM (Because it requires = more knowledge about source/group location). Once SSM is supported (*,G) = subscriptions would work as well. So I don=92t think discarding (*,G) = would make the solution easier. What I like with BIDIR is that you don=92t use tunneling even if you = have no idea where is the source located (which could happen quite often = if the source is from an ISP). But if you do, then you can optimize the = path. I have no experience using BIDIR thought (and am looking for an = IPv6 implementation for Linux, if anybody has one). >=20 >> 5) For autoconf PIM makes use of its own bootstrapping extension. = HNCP could be used as well for the exactly same purpose (election is = pretty obvious in HNCP). An extension would be really easy do define. = What do you think ? >=20 > Wouldn't it make sense that the HNCP elected routing would have a PIM = priority setting that would elect it to be PIM DR on the LAN as well? It makes sense. IMHO the most complicated part in PIM bootstrapping is = the message formatting and transmission. But I don=92t see any = capabilities or performances differences between PIM BS and HNCP. So = using HNCP for election is possible. >=20 > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se