From nobody Sun Jan 1 17:22:35 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0236A1279EB for ; Sun, 1 Jan 2017 17:22:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 2wUfFH-ZK7M3 for ; Sun, 1 Jan 2017 17:22:32 -0800 (PST) Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6306126BF6 for ; Sun, 1 Jan 2017 17:22:32 -0800 (PST) Received: by mail-pg0-x229.google.com with SMTP id g1so159493884pgn.0 for ; Sun, 01 Jan 2017 17:22:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rZiEoZcy7/eePqmF42rbgiPu6xUlqUQaKQXytYHIEAU=; b=kamQLMzVI4s7BhPeWQg8RvMnr71UQbfR7aakdPQFKPlyVpSyGwKuQ8PzsYuFaZnZwQ P5GkZJT/UfIbNQeigYAW8uLLURCaghyVh1U8EZOUW/8QwjvmZFw0h9RExexvSgKMBQRH Kvwzbt0fsbzeG2nUPXb9tV3rvf3ixJiJ4Xycoz00VSDDusczDCRnOMDsPxlYy7reTXAk 6T6DK3HiZHmWR4yXsFpFMgoS7v8C9cxmigmq7aMt/z7APEGQjRVXidc4I7zSVbFRi0P9 1DZ1NDy/APIVtcgJ6pqxTzRIqV1H7tmMsx2gkRW9kFWZJS0pOMuKKecp90pIgm5iaYSo G75w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rZiEoZcy7/eePqmF42rbgiPu6xUlqUQaKQXytYHIEAU=; b=Fc7AdAho0Pb4b+7vjP24/+BwdOyvSjOKrV82NiEr2yqrmzyH2I2FakTO0e8cqGSjax WtM4Ptga8LclpicDET/62gjqA38xrnkfg1v7Ku2oqucpX9VKg6AboY1qxR9IlveNVHFa EDll7t/XOCm/LMIQfJQKBMjprhuJ8GbPOOwT/c7M6dqx7iw2oKq1oxhTZP2bCVaagb6Q JUc3a92p25sKi702QE9vwhgcHNGonz/N+w5Y9WzIItq0pLrZOxEz9WuN2KqJ+uywyhMb E2A+MrTseBTlevhdNZQUwotMWdhgO3c+Qa73AOqMngWvPlhwhR0aK6OzMLii7CtnRjVB FSKQ== X-Gm-Message-State: AIkVDXLoglOgOpQNPJw4KXaDxcg1wZ0Ts9zla7RwcZ4r/M/mrRunhyB77q0jpMvl42VjCg== X-Received: by 10.84.136.75 with SMTP id 69mr120022657plk.52.1483320152366; Sun, 01 Jan 2017 17:22:32 -0800 (PST) Received: from [192.168.1.2] (wsip-184-191-158-59.sd.sd.cox.net. [184.191.158.59]) by smtp.gmail.com with ESMTPSA id d186sm84926832pfd.5.2017.01.01.17.22.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 01 Jan 2017 17:22:31 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Fred Baker In-Reply-To: Date: Sun, 1 Jan 2017 17:23:04 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <651319E6-BF0B-4700-B875-EA77440EB2C4@gmail.com> References: <6cc8fa42-cb66-816b-f000-3635cde9cc90@gmail.com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.3259) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] RFC6555 / Multiple interfaces X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2017 01:22:34 -0000 On Dec 30, 2016, at 9:01 PM, Mikael Abrahamsson = wrote: > This of course makes me a sad panda. It was done because of lack of = interest, but if people are interested in working in this area then if = we can gather enough people that show interest, AD might change his = mind. IMHO, MIF is readily solved, and is in fact solved in deployment in a = number of implementations. You put the software or hardware equivalent = of an L2 switch between the connected interfaces, so that to IP they are = in fact one interface, and a packet received on one is switched to the = another if and only if it is appropriate.=20 Solved, and anything that is more complex probably has bugs to be worked = out.= From nobody Sun Jan 1 17:23:26 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3DB2129474; Sun, 1 Jan 2017 17:23:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 vpumoQOpejTl; Sun, 1 Jan 2017 17:23:21 -0800 (PST) Received: from mail-pf0-x244.google.com (mail-pf0-x244.google.com [IPv6:2607:f8b0:400e:c00::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27E4312940C; Sun, 1 Jan 2017 17:23:21 -0800 (PST) Received: by mail-pf0-x244.google.com with SMTP id i88so23892634pfk.2; Sun, 01 Jan 2017 17:23:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kr64GpwmT9pqUf690fGTcinD85CLeMRdcFOI9xTxkmU=; b=Cc/15BE/l1h5fT1NF4kUT2/yWR0LnDHaw04k1xcspss9kB3U/AQuNT5LyOsNf76jtp pLn9gL2QjMMuOToA5YvoX90UipoRjQ9UZbBh3vqpDAjug+68NNwy9AggDpH4103KIml7 Lce4VlZTA2upJm6y6vk51jKXXFDnAtb9DFhavlew3T2Iw/p0Q6cseE6IoDTHRu+XEVY6 iSo0+zxvNBflUaUXoYhTSsWbOoKIUvhRcWGPAdbNXdjSwJu80CJgaeQJD6WP+a7WUFvp ohgiM9w905kQyMtcLoDfN18Yz9TFlgw5f/XTKRRrZdD/8lGXzFbNZPpm7jtd/cXQIDCW emVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kr64GpwmT9pqUf690fGTcinD85CLeMRdcFOI9xTxkmU=; b=TeujvUvv/qPnsBet1i2fvTuDD6xW62y54Qb5vwNOngCIcM/IZsx98i3O5fu5NgjcLJ 9ClHQI7k4aqrhLIEyoDgYAoZHYMKFB4HJJ4vxQZivFBzG8AD0V8Ft4AX0YAi92p+TyS9 UhtfxaxrY9228uYpIoMbpHTAX9i3jVR3zPw2w4j/04+E+NbUX9YNspxrlzajSU4rFgh8 OBxwnL+TYewZ5wnyLjhLpb6Wrh74rqOpoUfCHmoShGTZ+DgPayzcfBrcwbzB5qD17vQ3 xusvavaRVPsGaUQsN2n3rqaWu3x2p5Al667Im2Xb1xwYssKVPNYviGomas8X+aqwwQR/ MG7g== X-Gm-Message-State: AIkVDXK4KwW+z0JWA4RTxOMX81PvDw5f8/yxNhsIqncMkj4/8Ix9MQYUyfCxJWabQ4cmgw== X-Received: by 10.98.69.133 with SMTP id n5mr52651984pfi.160.1483320200691; Sun, 01 Jan 2017 17:23:20 -0800 (PST) Received: from [192.168.1.2] (wsip-184-191-158-59.sd.sd.cox.net. [184.191.158.59]) by smtp.gmail.com with ESMTPSA id d186sm84926832pfd.5.2017.01.01.17.23.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 01 Jan 2017 17:23:19 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Fred Baker In-Reply-To: <027a01d262e7$f30b30d0$d9219270$@riw.us> Date: Sun, 1 Jan 2017 17:23:53 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <9A4806E3-70B8-46E7-921D-4BA0817B16C7@gmail.com> References: <027a01d262e7$f30b30d0$d9219270$@riw.us> To: Russ White X-Mailer: Apple Mail (2.3259) Archived-At: Cc: draft-ali-ipv6rtr-reqs@tools.ietf.org, v6ops list , 6man WG Subject: Re: [v6ops] Comments on draft-ali-ipv6rtr-reqs-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2017 01:23:22 -0000 > On Dec 30, 2016, at 1:59 PM, Russ White wrote: >=20 >=20 >> It is indeed an individual draft, and to my knowledge no given = working > group >> has been asked for opinions. That said, we welcome any and all = review. >> Specifically, I have copied v6ops and 6man on this note. >=20 > We would like to present it to a WG as a work item--which WG would be = best > for this one? There are some sections that need to be filled before we > present it, I think. >=20 > :-) >=20 > Russ Personaly opinion: this isn=E2=80=99t about IPv6 per se, it is about the = operation of an IPv6 network. I=E2=80=99d suggest v6ops. From nobody Sun Jan 1 17:26:23 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A57C1279EB; Sun, 1 Jan 2017 17:26:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 QcJ1-l5Lhwfr; Sun, 1 Jan 2017 17:26:18 -0800 (PST) Received: from mail-pg0-x243.google.com (mail-pg0-x243.google.com [IPv6:2607:f8b0:400e:c05::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D132C126BF6; Sun, 1 Jan 2017 17:26:18 -0800 (PST) Received: by mail-pg0-x243.google.com with SMTP id g1so28975138pgn.0; Sun, 01 Jan 2017 17:26:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WvtMCtstMEjxlDTHke0VQgkGfioAEeyn76W/qgEH+Z0=; b=kfZ8xXmA0cMk9vxpTlQW7YjAOfDKnKWEtbKxO7nthED07J78AcsWSKeKpJJY4oJqnd Qv+TmLcuhU/XMnUzVAZ16zte7Ph4xIz8m45CRfGNb7Gt3+KHAZSPkbZ1bJSJIX1mKkGV SCTvd8voXxjYDOPRkiwLhMxeaufLDjDdi9GbEqqlV6oVtSq5pQZj4tOwKpcdM87wOdct vqLGDbnivLZPzjXwJrY08IG/V9H8USlKgLfRAB5hAgVMukUy+yxxSGi+YK+7Ruc7gY7j hh2harMz4zRWlPc9txE5wH5IzaKcCi+kj892mgpxxzByvlS5c3+Z/AXCFMdIFURcV1Vu CFxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WvtMCtstMEjxlDTHke0VQgkGfioAEeyn76W/qgEH+Z0=; b=ZIeT+ZAjY/xyjeEV10+eiSrx+YH61V0IFa0Etu68p++7w4gGQoT3VxX+EBHM309bmq 3V7wdok7CZJDDh6eiGdtDlbybtxLloS7k9k9xs6sjmJQaN//Rj4ebnd49NV6Wt594+rm OqrLAV+WZoMeI1AF0bInRixfZ6+Lf4vjCgOZphRVmLz5MaJfNXEZZiV9eC6gp5QBZ84K HRvTL9NVjrZdxHDak6Oh2BgIIyt4SWW0fxL3gyTTQSwF8/UHITvSA1DvJ3JdjEf/surr ueEknRFYvFFxIYOVoWfMPDwI0PGOITcm1jZkeZLnhMgh+2q/TW6hZFpkGNji8ge4XD1z 0FtA== X-Gm-Message-State: AIkVDXJEn1qM5mPWLzk1vXpjoKt/JgVf0Cn6oCHLFEqWf/ZAsl2VnspfdtuS6WBQD2+6xg== X-Received: by 10.84.216.2 with SMTP id m2mr115506737pli.31.1483320378208; Sun, 01 Jan 2017 17:26:18 -0800 (PST) Received: from [192.168.1.2] (wsip-184-191-158-59.sd.sd.cox.net. [184.191.158.59]) by smtp.gmail.com with ESMTPSA id k192sm108474364pgc.3.2017.01.01.17.26.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 01 Jan 2017 17:26:17 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Fred Baker In-Reply-To: <9A4806E3-70B8-46E7-921D-4BA0817B16C7@gmail.com> Date: Sun, 1 Jan 2017 17:26:50 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <88D7C907-1BD2-40E7-9DEA-5BAF42688046@gmail.com> References: <027a01d262e7$f30b30d0$d9219270$@riw.us> <9A4806E3-70B8-46E7-921D-4BA0817B16C7@gmail.com> To: Russ White X-Mailer: Apple Mail (2.3259) Archived-At: Cc: draft-ali-ipv6rtr-reqs@tools.ietf.org, v6ops list , 6man WG Subject: Re: [v6ops] Comments on draft-ali-ipv6rtr-reqs-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2017 01:26:20 -0000 > On Jan 1, 2017, at 5:23 PM, Fred Baker = wrote: >=20 >=20 >> On Dec 30, 2016, at 1:59 PM, Russ White wrote: >>=20 >>=20 >>> It is indeed an individual draft, and to my knowledge no given = working >> group >>> has been asked for opinions. That said, we welcome any and all = review. >>> Specifically, I have copied v6ops and 6man on this note. >>=20 >> We would like to present it to a WG as a work item--which WG would be = best >> for this one? There are some sections that need to be filled before = we >> present it, I think. >>=20 >> :-) >>=20 >> Russ >=20 > Personaly opinion: this isn=E2=80=99t about IPv6 per se, it is about = the operation of an IPv6 network. I=E2=80=99d suggest v6ops. Note that I=E2=80=99m not precluding 6man input. I=E2=80=99m asking what = change or clarification in IPv6 implementations (e.g., IPv6 Maintenance) = is called for. I don=E2=80=99t think there are any. I think it comments = on how IPv6 is used operationally, and by extension, what an operator = might expect to find in IPv6 implementations he deploys. From nobody Mon Jan 2 11:42:05 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3035C129467 for ; Mon, 2 Jan 2017 11:42:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.09 X-Spam-Level: X-Spam-Status: No, score=-4.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=sonusnetworks.onmicrosoft.com 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 3Ds6yrGgUEBO for ; Mon, 2 Jan 2017 11:42:01 -0800 (PST) Received: from us-smtp-delivery-211.mimecast.com (us-smtp-delivery-211.mimecast.com [63.128.21.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D95D129637 for ; Mon, 2 Jan 2017 11:42:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=3HQSFSgeQE8cV9iK5Gk3R/NTKqq9UkYJ+kcgs7C9/sU=; b=IIKlMge5WdvLGIYoIVl6Or/iDOjleaCRqnr/5hGHAJ7yAlgfWx2eOsjqKmuavKPy0eR9qn40Y5kTJOj1T050j1uz1r9CHocmG+oLB5eoDOejkwHwheZmR4nN1X1Yknt08aJ1h//tvsAXRxDK64fBbdd6OZFra3DY/4XFDUXZTlQ= Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01lp0175.outbound.protection.outlook.com [216.32.181.175]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-140-3-PdmWs0NFaZ5OhglINB3g-1; Mon, 02 Jan 2017 14:41:56 -0500 Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2351.namprd03.prod.outlook.com (10.166.210.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.11; Mon, 2 Jan 2017 19:41:52 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) by SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) with mapi id 15.01.0803.021; Mon, 2 Jan 2017 19:41:52 +0000 From: "Asveren, Tolga" To: Fred Baker , Mikael Abrahamsson Thread-Topic: [v6ops] RFC6555 / Multiple interfaces Thread-Index: AdJd8SFBepmXKJ7HSuuR2VCwtJY5xwB2CikAABQvbXAAANEQgAAWRS+AAQgXVC4AJijfEA== Date: Mon, 2 Jan 2017 19:41:51 +0000 Message-ID: References: <6cc8fa42-cb66-816b-f000-3635cde9cc90@gmail.com> <651319E6-BF0B-4700-B875-EA77440EB2C4@gmail.com> In-Reply-To: <651319E6-BF0B-4700-B875-EA77440EB2C4@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: 08f7d9b9-6312-42bd-4a1a-08d43347667d x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SN2PR03MB2351; x-microsoft-exchange-diagnostics: 1; SN2PR03MB2351; 7:KzrMuoAQ90BwxnrCgl+7ZkquSPOkbz8IpSzeH1uW0991VdXSAxJn4cG9n2Ibn8rvZby82QrcOKLjOL2UkFtNyUdB+VMJCvI8QzGiu+btHlz/S9KmyRJQTmpAkKhpmQBLTSvIEHs+WJttH31AwCYjbkCfbeXdZmNoePw2P0vM+TDZizTegEpc0kLv4MNrvMD4lsIzPhtlZ/EuNEtjef9xlWdc7wY32ogitEw9/t4Lw0VdfADi+onRMJaeoVITSISsbHEOj/h6cFuf3idSWmC8WshEW0oexYr4cE+U/YuS03VErYOcYVAOI7LYvfohQ+2+INCeltclcd7qeqwDk2XF5Fx/sLqAr9lyZQix1Ujb9lkDs0mTYsLEByZMw1X1ovJdCt4sYHi2VcTSmfHI183hb0mKFW3Wjdt25v098O2tfivOU9ePzBX6kgUkVdUsaK3L66IBOD0TLkd4qzIj6D4m4A== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6072148)(6047074); SRVR:SN2PR03MB2351; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2351; x-forefront-prvs: 017589626D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(13464003)(24454002)(189002)(199003)(377454003)(106356001)(77096006)(7696004)(74316002)(86362001)(5660300001)(38730400001)(7736002)(6436002)(81166006)(25786008)(2906002)(2900100001)(122556002)(4326007)(6506006)(3660700001)(229853002)(8936002)(33656002)(9686002)(2950100002)(3280700002)(99286003)(50986999)(66066001)(189998001)(81156014)(5001770100001)(305945005)(92566002)(8676002)(39060400001)(55016002)(3846002)(102836003)(76176999)(68736007)(97736004)(6116002)(93886004)(101416001)(54356999)(105586002); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2351; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jan 2017 19:41:52.0013 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2351 X-MC-Unique: 3-PdmWs0NFaZ5OhglINB3g-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] RFC6555 / Multiple interfaces X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2017 19:42:04 -0000 I would like to (re)express my interest in defining how happy-eyeballs (RFC= 6555) should behave in the context of multiple interfaces. I think draft-ie= tf-mif-happy-eyeballs-extension-11 could be a good candidate for that but I= also have to admit I was hoping for something with less procedures/simpler= -which may/may not be possible/a good idea at the end-. Thanks, Tolga > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Fred Baker > Sent: Sunday, January 01, 2017 8:23 PM > To: Mikael Abrahamsson > Cc: v6ops@ietf.org > Subject: Re: [v6ops] RFC6555 / Multiple interfaces >=20 >=20 > On Dec 30, 2016, at 9:01 PM, Mikael Abrahamsson > wrote: > > This of course makes me a sad panda. It was done because of lack of > interest, but if people are interested in working in this area then if we= can > gather enough people that show interest, AD might change his mind. >=20 > IMHO, MIF is readily solved, and is in fact solved in deployment in a num= ber > of implementations. You put the software or hardware equivalent of an L2 > switch between the connected interfaces, so that to IP they are in fact o= ne > interface, and a packet received on one is switched to the another if and= only > if it is appropriate. >=20 > Solved, and anything that is more complex probably has bugs to be worked > out. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Jan 2 12:08:45 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5526129706 for ; Mon, 2 Jan 2017 12:08:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 FMc75dwqVLp9 for ; Mon, 2 Jan 2017 12:08:42 -0800 (PST) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67EE91296B4 for ; Mon, 2 Jan 2017 12:08:42 -0800 (PST) Received: by mail-pg0-x22f.google.com with SMTP id f188so206474663pgc.3 for ; Mon, 02 Jan 2017 12:08:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jFrvB6D6G6WLCyTLA0cDVJ4wRHkmgORx4ihqaG1kQoE=; b=jSzKBzs3YcBCi1xxgK1+UceSr9LJ4d7jgamBcZqzxrpxDcfbs2rZxBSOSIVWFHPbYE AfJqzF9RFkWhhm7FKIXtUSabObhX1ZNkldQTFkLvQEaEIOlGe/ThozVGVlH2+K2PNdtn 7wSJq97YM34+7rDfRxV7BSUWosIntFk+fzo02dV1oAGM1sHlhXM/N+eades9U13fnfQM Se7QUDQ2ZvvdvulS8g+gRJhgnJuugHAzJ+GSz34HOlFM/kEp1OMK9oumGVyYJ49k0luX Hy9NfuMUkuyERsrcbcO/MCZqOglNR33xJVdxVtr/z2dWpxnU1DaAadwHxFaYRX//CoYq xUww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jFrvB6D6G6WLCyTLA0cDVJ4wRHkmgORx4ihqaG1kQoE=; b=te5zSOIFPQzdKumV7SR8w5RpPbmiL10m3ERQw1zqYt2moBoMft/+Cdrwqjk3dI9CJf sDex4cErxjiqKRx1+xubA3oQ9z1Yyfx58hWUZPVEuuRh/6/iNCW3WhVS/lBDB5W1BSX6 TE22/T8c5QANdekUeaD71moVSVJPZCCtiOSaBZ/v2wqFyKf7S6iUcNNhMVs2+aRyBjAM 7yem/a/a34402/ycdzVDpNQFjgMLe6z5yJAra7dhYwtyETtudDGB4BDtmGDZB1gwKTXB HA2c/Hknfn/H/bfH6AshBMl1k96ZNKHsFcgR3yBqAyARZHTQ5B5y9lIrrmxDKS1BfWko fDLA== X-Gm-Message-State: AIkVDXKFEPCSuYsvMMM2Tw1eMlPsZgYemMiJ8dSwhjOoRviUH6RadE4e3NaPFN98wBZpZQ== X-Received: by 10.84.202.163 with SMTP id x32mr128824619pld.46.1483387721936; Mon, 02 Jan 2017 12:08:41 -0800 (PST) Received: from [192.168.1.2] (wsip-184-191-158-59.sd.sd.cox.net. [184.191.158.59]) by smtp.gmail.com with ESMTPSA id l11sm134213530pfb.28.2017.01.02.12.08.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Jan 2017 12:08:40 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Fred Baker In-Reply-To: Date: Mon, 2 Jan 2017 12:09:18 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6cc8fa42-cb66-816b-f000-3635cde9cc90@gmail.com> <651319E6-BF0B-4700-B875-EA77440EB2C4@gmail.com> To: "Asveren, Tolga" X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] RFC6555 / Multiple interfaces X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2017 20:08:44 -0000 On Jan 2, 2017, at 11:41 AM, Asveren, Tolga = wrote: > I would like to (re)express my interest in defining how happy-eyeballs = (RFC6555) should behave in the context of multiple interfaces. I think = draft-ietf-mif-happy-eyeballs-extension-11 could be a good candidate for = that but I also have to admit I was hoping for something with less = procedures/simpler -which may/may not be possible/a good idea at the = end-. Again, speaking strictly for myself. One of the big problems with IPv6 deployment, perhaps the biggest single = problem, is that the badly broken socket interface forces the = application to know about and select the address that will be used for a = given session. There is no need for that if an API is included that = allows the application to find out what address it is using should it = need that. If the application were to give the OS a character string = (which might be an address literal, a domain name, or something else of = local significance) and the OS returned an open socket or an error code, = many applications would have ported long ago without a thought; as it = is, the case needs to be made to each application individually. The best = bet is steps such as Apple has taken - =E2=80=9Chow badly do you want = your application to be available through our distribution service? Just = Do It.=E2=80=9D The downside of Happy Eyeballs is that it asks the application to do = something more complex than changing the name of the API called and the = size of the container the address is stored in; it tells the application = that it needs to walk a list of addresses and potentially have more than = one connection in progress at any given time. If it were an OS service, = we could change the OS once and have HE implemented for all = applications. Making the requested action more complex makes =E2=80=9Cmaki= ng the case to every individual application=E2=80=9D harder. And then there is draft-ietf-mif-happy-eyeballs-extension. IMHO, an = implementation report, as in =E2=80=9Capplication X, Y, and Z did it on = multiple platforms, and provably interoperate using it=E2=80=9D, would = be in order.= From nobody Mon Jan 2 15:12:41 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 728EF129502 for ; Mon, 2 Jan 2017 15:12:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10 X-Spam-Level: X-Spam-Status: No, score=-10 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1] autolearn=ham autolearn_force=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 fojWu55FkNVO for ; Mon, 2 Jan 2017 15:12:39 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3772129504 for ; Mon, 2 Jan 2017 15:12:38 -0800 (PST) Received: from mbp-4.local (c-73-96-132-59.hsd1.or.comcast.net [73.96.132.59]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id v02NCatr064413 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 2 Jan 2017 23:12:36 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host c-73-96-132-59.hsd1.or.comcast.net [73.96.132.59] claimed to be mbp-4.local To: Fred Baker , "Asveren, Tolga" References: <6cc8fa42-cb66-816b-f000-3635cde9cc90@gmail.com> <651319E6-BF0B-4700-B875-EA77440EB2C4@gmail.com> From: joel jaeggli Message-ID: <09a4f40a-e996-df5f-23cb-771d1ac144c5@bogus.com> Date: Mon, 2 Jan 2017 15:12:30 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:50.0) Gecko/20100101 Thunderbird/50.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7tlqbCmu6xUBKafSjgKjNPAul1O2fVbJL" Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] RFC6555 / Multiple interfaces X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2017 23:12:40 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7tlqbCmu6xUBKafSjgKjNPAul1O2fVbJL Content-Type: multipart/mixed; boundary="IHnDJqk0T9g1lu9fVG3p1AFRTeq7CvJpL"; protected-headers="v1" From: joel jaeggli To: Fred Baker , "Asveren, Tolga" Cc: "v6ops@ietf.org" Message-ID: <09a4f40a-e996-df5f-23cb-771d1ac144c5@bogus.com> Subject: Re: [v6ops] RFC6555 / Multiple interfaces References: <6cc8fa42-cb66-816b-f000-3635cde9cc90@gmail.com> <651319E6-BF0B-4700-B875-EA77440EB2C4@gmail.com> In-Reply-To: --IHnDJqk0T9g1lu9fVG3p1AFRTeq7CvJpL Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US On 1/2/17 12:09 PM, Fred Baker wrote: > On Jan 2, 2017, at 11:41 AM, Asveren, Tolga wro= te: >> I would like to (re)express my interest in defining how happy-eyeballs= (RFC6555) should behave in the context of multiple interfaces. I think d= raft-ietf-mif-happy-eyeballs-extension-11 could be a good candidate for t= hat but I also have to admit I was hoping for something with less procedu= res/simpler -which may/may not be possible/a good idea at the end-. > Again, speaking strictly for myself. > > One of the big problems with IPv6 deployment, perhaps the biggest singl= e problem, is that the badly broken socket interface forces the applicati= on to know about and select the address that will be used for a given ses= sion. There is no need for that if an API is included that allows the app= lication to find out what address it is using should it need that. If the= application were to give the OS a character string (which might be an ad= dress literal, a domain name, or something else of local significance) an= d the OS returned an open socket or an error code, many applications woul= d have ported long ago without a thought; as it is, the case needs to be = made to each application individually. The best bet is steps such as Appl= e has taken - =E2=80=9Chow badly do you want your application to be avail= able through our distribution service? Just Do It.=E2=80=9D > > The downside of Happy Eyeballs is that it asks the application to do so= mething more complex than changing the name of the API called and the siz= e of the container the address is stored in; it tells the application tha= t it needs to walk a list of addresses and potentially have more than one= connection in progress at any given time. If it were an OS service, we c= ould change the OS once and have HE implemented for all applications. Mak= ing the requested action more complex makes =E2=80=9Cmaking the case to e= very individual application=E2=80=9D harder. On one hand we have applications such as web browsers that implement their own stack from the ground up. Their behavior is both different and opaque to the operating systems. On the other we have considerations other than which one performs the fastest such as cost, or order of installation (e.g. if your vpn default is the last one installed it's probably the cause that you intended to use that), that transcend questions of whether or not I should try multiple address families on different interfaces... I wonder whether this can be formulated as a nice tight algorithm or if this is just a set of heuristics that need to be incompletely applied depending on your use case. > > And then there is draft-ietf-mif-happy-eyeballs-extension. IMHO, an imp= lementation report, as in =E2=80=9Capplication X, Y, and Z did it on mult= iple platforms, and provably interoperate using it=E2=80=9D, would be in = order. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --IHnDJqk0T9g1lu9fVG3p1AFRTeq7CvJpL-- --7tlqbCmu6xUBKafSjgKjNPAul1O2fVbJL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlhq3l8ACgkQ8AA1q7Z/VrKvtgCfXiqaJYVBetkxjitKm43dH1Lx amIAmQGbf1t84tqTlb6/5t+niK7yhLOv =JnB5 -----END PGP SIGNATURE----- --7tlqbCmu6xUBKafSjgKjNPAul1O2fVbJL-- From nobody Mon Jan 2 16:39:27 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB02129521 for ; Mon, 2 Jan 2017 16:39:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 altTCFmfqfER for ; Mon, 2 Jan 2017 16:39:26 -0800 (PST) Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB1FE12951F for ; Mon, 2 Jan 2017 16:39:25 -0800 (PST) Received: by mail-pg0-x233.google.com with SMTP id g1so169163802pgn.0 for ; Mon, 02 Jan 2017 16:39:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Pymt6f2JUT1ML87zRQObPhEgR6bWCegDQcVX2BJkDEk=; b=DR2/K3u8zIJ594rJFD6HXCod+mhesXXNSkZAHaI6jFQ+JhjfNQZM9bkbaGsT9dgXGc S29fmdWp1h0GhrkxSme4phmPxSlv68i+V4ERy1RKPr8MWVVK5Qii6qnaZqhMcsmxK4gQ XaBB6GW0YpCepYpB/AtsVk3zELxQG95OQaCdu/DiBb0qlzLP5rNWxg+nHXE1WtcH9dAc qoaDf9o06ystfQDIBDj3ROA9tNxWKVFQuTryJ/xFo0avZ/ZxiYKYXeqVaS19gTVM96vV jYQ6MD5bI43McVnGMwKS7G4LF+oV1a//x38j8dq4h82/j1NvtRSMOC+b/1XW7DjTFD9X U7ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Pymt6f2JUT1ML87zRQObPhEgR6bWCegDQcVX2BJkDEk=; b=d8BWElL6PBYRQ/VilMPnFXTD9E7ewOBy1yLAmr0Lwli+RqZ5u42rlgMrEyPZ7peETy V0Tr5Kg7IuaKNkSianP59h29Ey/S6j2BZ8D25hiKMmusP5iWfiGYmw5gF62fJL/UNgXo Qdo1GoJ66lO4i/XltzRNSwRiGv0daCLHeX0wx2LxL0ab2TprFX1c3s+nZtSviyTTP3ss mrmxNdN3zI+2YUKJftMr+O5hOwic1noUQj1/y0aE7ewFjeMyks2zbPOR/SflY/zVzdj9 QGrXEPSvouGIvDls4xdnW6RGGSQsyVJzQmh8x/28OSHWJTrOsriCZagRU+OMVXyP0zl6 pW3w== X-Gm-Message-State: AIkVDXKo4bR5lp95t/HG3AVawZexQBUtF29FwpoAteWnRaRD4b1mX3StXAiUjwJRB9Txgg== X-Received: by 10.99.158.18 with SMTP id s18mr111480843pgd.88.1483403965537; Mon, 02 Jan 2017 16:39:25 -0800 (PST) Received: from [192.168.1.2] (wsip-184-191-158-59.sd.sd.cox.net. [184.191.158.59]) by smtp.gmail.com with ESMTPSA id t184sm135769141pgt.36.2017.01.02.16.39.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Jan 2017 16:39:24 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Fred Baker In-Reply-To: <09a4f40a-e996-df5f-23cb-771d1ac144c5@bogus.com> Date: Mon, 2 Jan 2017 16:39:23 -0800 Content-Transfer-Encoding: 7bit Message-Id: References: <6cc8fa42-cb66-816b-f000-3635cde9cc90@gmail.com> <651319E6-BF0B-4700-B875-EA77440EB2C4@gmail.com> <09a4f40a-e996-df5f-23cb-771d1ac144c5@bogus.com> To: joel jaeggli X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] RFC6555 / Multiple interfaces X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 00:39:27 -0000 > On Jan 2, 2017, at 3:12 PM, joel jaeggli wrote: > > I wonder whether this can be formulated as a nice tight algorithm or if > this is just a set of heuristics that need to be incompletely applied > depending on your use case. Probably that. From nobody Tue Jan 3 03:58:09 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6417129437 for ; Tue, 3 Jan 2017 03:58:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.09 X-Spam-Level: X-Spam-Status: No, score=-4.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=sonusnetworks.onmicrosoft.com 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 pe5RzRXWzlsC for ; Tue, 3 Jan 2017 03:58:06 -0800 (PST) Received: from us-smtp-delivery-211.mimecast.com (us-smtp-delivery-211.mimecast.com [216.205.24.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4E2B1293FC for ; Tue, 3 Jan 2017 03:58:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=F536FRvx7mgbEwlsk98vsY5iu+xsHQCGkjsCaaDim+4=; b=aHBx1y/AytXbPGS9FrXIBOtq8rOFVu3sPQmEmHSTkWYC+qwCF7qElHlxIWYfxXChogdqyyTE+k9PSBLWjUTDfRQhikTO9fzLrDzZfK9owlxC5vibnfly1PPFoCGeQ7gwuQJ2iO0m2laePW2kcwQGTQyOxvUOFoGWydo382A87ag= Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02lp0079.outbound.protection.outlook.com [207.46.163.79]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-23-dUe7f8sROiS6XAhrD27yMg-1; Tue, 03 Jan 2017 06:58:02 -0500 Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2352.namprd03.prod.outlook.com (10.166.210.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.11; Tue, 3 Jan 2017 11:58:00 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) by SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) with mapi id 15.01.0803.021; Tue, 3 Jan 2017 11:58:00 +0000 From: "Asveren, Tolga" To: Fred Baker , joel jaeggli Thread-Topic: [v6ops] RFC6555 / Multiple interfaces Thread-Index: AdJd8SFBepmXKJ7HSuuR2VCwtJY5xwB2CikAABQvbXAAANEQgAAWRS+AAQgXVC4AJijfEAABLeoAAAZl7wAAAwjNgAAUfRJg Date: Tue, 3 Jan 2017 11:58:00 +0000 Message-ID: References: <6cc8fa42-cb66-816b-f000-3635cde9cc90@gmail.com> <651319E6-BF0B-4700-B875-EA77440EB2C4@gmail.com> <09a4f40a-e996-df5f-23cb-771d1ac144c5@bogus.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: abdd0b0f-57ff-4e68-4ef2-08d433cfc42f x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SN2PR03MB2352; x-microsoft-exchange-diagnostics: 1; SN2PR03MB2352; 7:svvGD8izUeIGPDEOKd3XnutmMSB7ed/R7xaW9uluFOz3vTb7FZ0/D1ZKbwahEzSO6Aw21NhJWS2F6pmTRK2zGR27dDOfjA5n33jC1ZOuuTEzIyUdZQzQrb84Nomzme5tlSb1aeJaDgi+8ZAk55Hulbvt/ozy+D0F26bN0p1KuZuJjW4ReOlFwt3mrqGzCkm3QGuWV5OVztlPRsY20Pf0fQuhBisoKFUzKTBVOge1EvBHATCcCycX6aRSrnIK+bGtwR6t1KD3rl+qYQ6VYbNzHBpAWg9A0JP8T8/hnQtQSxrTnkKyBiQX4TX6dr/Ac4qhOP8BcfEbjiTNS5zU0Ms35hK+FbSKRvwNBk0QFpzyw8J9IJ4/kqnD+ByDnyyXJ5BUq1VA1XqWpKnjNvO3bmFt3VxcMDaaWiufhde7TDNIobAZuDSQwxOFHlzuWJV4cuMRXw45grEQsNmu80PoIKZmbw== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123555025)(20161123560025)(20161123558021)(20161123564025)(20161123562025)(6072148)(6047074); SRVR:SN2PR03MB2352; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2352; x-forefront-prvs: 01762B0D64 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(199003)(189002)(377454003)(24454002)(13464003)(305945005)(76176999)(122556002)(33656002)(50986999)(81156014)(39060400001)(81166006)(6116002)(8676002)(99286003)(25786008)(6506006)(7696004)(86362001)(2950100002)(38730400001)(106356001)(77096006)(68736007)(9686002)(229853002)(55016002)(4326007)(102836003)(5001770100001)(3660700001)(97736004)(105586002)(2906002)(101416001)(66066001)(6436002)(189998001)(93886004)(54356999)(3280700002)(74316002)(8936002)(3846002)(5660300001)(92566002)(2900100001)(7736002); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2352; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jan 2017 11:58:00.7092 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2352 X-MC-Unique: dUe7f8sROiS6XAhrD27yMg-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] RFC6555 / Multiple interfaces X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 11:58:08 -0000 Maybe a two-step approach? i- "Entities following procedures in RFC6555 SHOULD perform connection chec= ks for each interface in parallel, if an IP Address Family can utilize more= than one interface. While doing so, they MAY consider other factor and par= ameters, e.g. a priori knowledge about user preferences for particular appl= ications, interface capabilities." IMHO this should be stated in a "Standards Track" specification. ii- Other specifications, probably all/mostly "Informational", providing re= commendations about Socket API usage, interface type specific procedures et= c... Would such a split make sense? I know i- could be considered as "too little= /no brainer" but that arguably may be true for RFC6555 in general -especail= ly the "obviousness"-. Thanks, Tolga > -----Original Message----- > From: Fred Baker [mailto:fredbaker.ietf@gmail.com] > Sent: Monday, January 02, 2017 7:39 PM > To: joel jaeggli > Cc: Asveren, Tolga ; v6ops@ietf.org > Subject: Re: [v6ops] RFC6555 / Multiple interfaces >=20 >=20 > > On Jan 2, 2017, at 3:12 PM, joel jaeggli wrote: > > > > I wonder whether this can be formulated as a nice tight algorithm or > > if this is just a set of heuristics that need to be incompletely > > applied depending on your use case. >=20 > Probably that. From nobody Tue Jan 3 08:07:26 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D00C129A51 for ; Tue, 3 Jan 2017 08:07:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.11 X-Spam-Level: X-Spam-Status: No, score=-4.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=jisc365.onmicrosoft.com 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 1tlBZuNhh4mk for ; Tue, 3 Jan 2017 08:07:17 -0800 (PST) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5089D129579 for ; Tue, 3 Jan 2017 08:07:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc365.onmicrosoft.com; s=selector1-jisc-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=YNK00hY3ZOBhRWZNCRRTCgYm1JjbXV9xp8+E2k4JwPg=; b=VDJB3LuTtbGvX2rCtV4lwYCKgH/laPgUiGao8qkfOyhF0ZRmHHuWHcErVqmMIKax4hc9ClNvnAbLXf58TSlrYh1XtUUlQx+DEY7D8jXGjU+5d9D8+mtp5/GTpzK/OszpVu24Y9eNgkKqyuvLXNKoarnkDoFEnVR7SKOJWEC2mzw= Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01lp0177.outbound.protection.outlook.com [213.199.154.177]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-7-p7cvkOG0Oo2AFTVT03O_TA-1; Tue, 03 Jan 2017 16:07:10 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1138.eurprd07.prod.outlook.com (10.163.188.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.829.4; Tue, 3 Jan 2017 16:07:07 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::292e:d46e:7c2b:75c6]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::292e:d46e:7c2b:75c6%15]) with mapi id 15.01.0829.003; Tue, 3 Jan 2017 16:07:07 +0000 From: Tim Chown To: Fred Baker Thread-Topic: [v6ops] Comments on draft-ali-ipv6rtr-reqs-01 Thread-Index: AQHSYUSKP4RyXDRcfEW58qB9cBducaEd5l2AgAMk2QCAAAIlgIADXd2AgAKJGgA= Date: Tue, 3 Jan 2017 16:07:07 +0000 Message-ID: <26DE8EFE-ABA9-4754-BBD1-B9651797DDC0@jisc.ac.uk> References: <027a01d262e7$f30b30d0$d9219270$@riw.us> <9A4806E3-70B8-46E7-921D-4BA0817B16C7@gmail.com> In-Reply-To: <9A4806E3-70B8-46E7-921D-4BA0817B16C7@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3259) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:a88:d510:1101:486a:8527:1c03:59ba] x-ms-office365-filtering-correlation-id: 707e7db3-4a05-42b1-b857-08d433f2913a x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:AM3PR07MB1138; x-microsoft-exchange-diagnostics: 1; AM3PR07MB1138; 7:k76gt5Eyprps22ds9vHuTKt1nWsyRuxZ2uThJuTQPUy9Jp7VKFYHr6Y8sTNpKdayd41t3er904b4tMM2NeVMtCOcmCO9DCLPe/ugSjiAZGLu5soQe+7RDLH6vd+GfC/wvuXtoaaRvCDjemI+EK5lMb9JPOesSVD+PWnRb6z30uOhrwdAQbi8/iNgG08dEeRRyvyjAQN3ayHYt+sofUbGCTSUeqZIxnj8H2qT5gaeNfIypoY0ClqTOfLY93lO9jWB/D0OLHgG+KBzkPIeQzCbzzRg9BbTpknmNpaJmSJ/D6Y1MWylyj0HgIet4W2zOYJEY668gQ+SoaDM6h6OKClFFosa9WpOxQylAtkDRs2ePQv10Em3ReXou7qZgCc91tTW/GTOlSazdD69owW4pr1gsCFL59un+dQrvax3MWX9uYnbghv5gi+e04K7tBSinqga/+KzOLQFJLtsm3VDPGzf+g==; 20:xOSdz/xL36ZNclcfAQ/SNnNiXrf0lLgbHZeV1jsY8kTdCTSIdqpOeE8Nos0tuVHhebHdSTZGUc48fM7HRIs0ag29TuOM9UmZLZyZwtj1/n5gb5KexeY1qk1V4WHjoxKn/j8ZRvxnz2dAuQNyypqVrmGIIHlycN5wRt8JOeFLnZU= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6072148); SRVR:AM3PR07MB1138; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1138; x-forefront-prvs: 01762B0D64 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(39450400003)(189002)(24454002)(377454003)(199003)(2950100002)(6486002)(189998001)(81156014)(81166006)(6916009)(50226002)(42882006)(39060400001)(5250100002)(8676002)(6506006)(6512006)(8936002)(93886004)(6116002)(102836003)(86362001)(74482002)(38730400001)(229853002)(230783001)(106356001)(106116001)(82746002)(97736004)(110136003)(7736002)(83716003)(105586002)(6436002)(99286003)(68736007)(76176999)(101416001)(57306001)(36756003)(5660300001)(4326007)(2900100001)(92566002)(50986999)(33656002)(3280700002)(2906002)(3660700001)(54906002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1138; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jan 2017 16:07:07.5597 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1138 X-MC-Unique: p7cvkOG0Oo2AFTVT03O_TA-1 Content-Type: multipart/alternative; boundary="_000_26DE8EFEABA94754BBD1B9651797DDC0jiscacuk_" Archived-At: Cc: Russ White , "draft-ali-ipv6rtr-reqs@tools.ietf.org" , 6man WG , v6ops list Subject: Re: [v6ops] Comments on draft-ali-ipv6rtr-reqs-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 16:07:19 -0000 --_000_26DE8EFEABA94754BBD1B9651797DDC0jiscacuk_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 SGksDQoNCk9uIDIgSmFuIDIwMTcsIGF0IDAxOjIzLCBGcmVkIEJha2VyIDxGcmVkQmFrZXIuSUVU RkBnbWFpbC5jb208bWFpbHRvOkZyZWRCYWtlci5JRVRGQGdtYWlsLmNvbT4+IHdyb3RlOg0KDQpP biBEZWMgMzAsIDIwMTYsIGF0IDE6NTkgUE0sIFJ1c3MgV2hpdGUgPHJ1c3NAcml3LnVzPG1haWx0 bzpydXNzQHJpdy51cz4+IHdyb3RlOg0KDQpJdCBpcyBpbmRlZWQgYW4gaW5kaXZpZHVhbCBkcmFm dCwgYW5kIHRvIG15IGtub3dsZWRnZSBubyBnaXZlbiB3b3JraW5nDQpncm91cA0KaGFzIGJlZW4g YXNrZWQgZm9yIG9waW5pb25zLiBUaGF0IHNhaWQsIHdlIHdlbGNvbWUgYW55IGFuZCBhbGwgcmV2 aWV3Lg0KU3BlY2lmaWNhbGx5LCBJIGhhdmUgY29waWVkIHY2b3BzIGFuZCA2bWFuIG9uIHRoaXMg bm90ZS4NCg0KV2Ugd291bGQgbGlrZSB0byBwcmVzZW50IGl0IHRvIGEgV0cgYXMgYSB3b3JrIGl0 ZW0tLXdoaWNoIFdHIHdvdWxkIGJlIGJlc3QNCmZvciB0aGlzIG9uZT8gVGhlcmUgYXJlIHNvbWUg c2VjdGlvbnMgdGhhdCBuZWVkIHRvIGJlIGZpbGxlZCBiZWZvcmUgd2UNCnByZXNlbnQgaXQsIEkg dGhpbmsuDQoNCjotKQ0KDQpSdXNzDQoNClBlcnNvbmFseSBvcGluaW9uOiB0aGlzIGlzbuKAmXQg YWJvdXQgSVB2NiBwZXIgc2UsIGl0IGlzIGFib3V0IHRoZSBvcGVyYXRpb24gb2YgYW4gSVB2NiBu ZXR3b3JrLiBJ4oCZZCBzdWdnZXN0IHY2b3BzLg0KDQpJIGxvb2tlZCB0aHJvdWdoIHRoaXMgZHJh ZnQgcXVpY2tseSBhcyBpdCBzZWVtZWQgdG8gYmUgcmVsZXZhbnQgdG8gdGhlIG9uZ29pbmcgNm1h biB3b3JrIG9uIHVwZGF0aW5nIFJGQyA2NDM0LCBJUHY2IE5vZGUgUmVxdWlyZW1lbnRzLg0KDQpJ IGxpa2UgdGhlIHN0eWxlIGl04oCZcyB3cml0dGVuIGluLCBhbmQgdGhlIGJsZW5kIG9mIGFkdmlj ZSBiZWluZyBnaXZlbi4gSXQgcmVhZHMgbmljZWx5Lg0KDQpJIHRoaW5rIHRoaXMgZHJhZnQgdHJl YWRzIG1vcmUgaGVhdmlseSBpbnRvIG9wZXJhdGlvbmFsIGFuZCBkZXNpZ24gcmVxdWlyZW1lbnRz LCByYXRoZXIgdGhhbiBqdXN0IGJlaW5nIGEgbGlzdCBvZiBwcm90b2NvbCByZXF1aXJlbWVudHMs IHNvIEnigJlkIGFsc28gc2F5IGl0IGxvb2tzIG1vcmUgbGlrZSBhIHY2b3BzIGRvY3VtZW50LCBh bmQgaXQgY291bGQgcHJvYmFibHkgYmUgcmVuYW1lZCB0byBtYXRjaCB0aGF0IGVtcGhhc2lzLg0K DQpUaW0NCg== --_000_26DE8EFEABA94754BBD1B9651797DDC0jiscacuk_ Content-Type: text/html; charset=UTF-8 Content-ID: <7B04B94C04A8CA4DB4629B10F21A976C@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGksDQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxk aXYgY2xhc3M9IiI+T24gMiBKYW4gMjAxNywgYXQgMDE6MjMsIEZyZWQgQmFrZXIgJmx0OzxhIGhy ZWY9Im1haWx0bzpGcmVkQmFrZXIuSUVURkBnbWFpbC5jb20iIGNsYXNzPSIiPkZyZWRCYWtlci5J RVRGQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNp emU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsg Zm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0 bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBu b25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4 OyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lk dGg6IDBweDsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5l Ij4NCk9uIERlYyAzMCwgMjAxNiwgYXQgMTo1OSBQTSwgUnVzcyBXaGl0ZSAmbHQ7PGEgaHJlZj0i bWFpbHRvOnJ1c3NAcml3LnVzIiBjbGFzcz0iIj5ydXNzQHJpdy51czwvYT4mZ3Q7IHdyb3RlOjxi ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNz PSIiPkl0IGlzIGluZGVlZCBhbiBpbmRpdmlkdWFsIGRyYWZ0LCBhbmQgdG8gbXkga25vd2xlZGdl IG5vIGdpdmVuIHdvcmtpbmc8YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQpncm91cDxiciBj bGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPmhhcyBiZWVuIGFza2Vk IGZvciBvcGluaW9ucy4gVGhhdCBzYWlkLCB3ZSB3ZWxjb21lIGFueSBhbmQgYWxsIHJldmlldy48 YnIgY2xhc3M9IiI+DQpTcGVjaWZpY2FsbHksIEkgaGF2ZSBjb3BpZWQgdjZvcHMgYW5kIDZtYW4g b24gdGhpcyBub3RlLjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4N CldlIHdvdWxkIGxpa2UgdG8gcHJlc2VudCBpdCB0byBhIFdHIGFzIGEgd29yayBpdGVtLS13aGlj aCBXRyB3b3VsZCBiZSBiZXN0PGJyIGNsYXNzPSIiPg0KZm9yIHRoaXMgb25lPyBUaGVyZSBhcmUg c29tZSBzZWN0aW9ucyB0aGF0IG5lZWQgdG8gYmUgZmlsbGVkIGJlZm9yZSB3ZTxiciBjbGFzcz0i Ij4NCnByZXNlbnQgaXQsIEkgdGhpbmsuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KOi0p PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KUnVzczxiciBjbGFzcz0iIj4NCjwvYmxvY2tx dW90ZT4NCjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4 OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2Vp Z2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQt YWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hp dGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtp dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZv bnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFj aW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVu dDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dz OiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4 OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5QZXJz b25hbHkNCiBvcGluaW9uOiB0aGlzIGlzbuKAmXQgYWJvdXQgSVB2NiBwZXIgc2UsIGl0IGlzIGFi b3V0IHRoZSBvcGVyYXRpb24gb2YgYW4gSVB2NiBuZXR3b3JrLiBJ4oCZZCBzdWdnZXN0IHY2b3Bz Ljwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJw eDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdl aWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0 LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdo aXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJr aXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JIGxvb2tl ZCB0aHJvdWdoIHRoaXMgZHJhZnQgcXVpY2tseSBhcyBpdCBzZWVtZWQgdG8gYmUgcmVsZXZhbnQg dG8gdGhlIG9uZ29pbmcgNm1hbiB3b3JrIG9uIHVwZGF0aW5nIFJGQyA2NDM0LCBJUHY2IE5vZGUg UmVxdWlyZW1lbnRzLiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SSBsaWtlIHRoZSBzdHlsZSBpdOKAmXMgd3JpdHRlbiBpbiwg YW5kIHRoZSBibGVuZCBvZiBhZHZpY2UgYmVpbmcgZ2l2ZW4uIEl0IHJlYWRzIG5pY2VseS48L2Rp dj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkkg dGhpbmsgdGhpcyBkcmFmdCB0cmVhZHMgbW9yZSBoZWF2aWx5IGludG8gb3BlcmF0aW9uYWwgYW5k IGRlc2lnbiByZXF1aXJlbWVudHMsIHJhdGhlciB0aGFuIGp1c3QgYmVpbmcgYSBsaXN0IG9mIHBy b3RvY29sIHJlcXVpcmVtZW50cywgc28gSeKAmWQgYWxzbyBzYXkgaXQgbG9va3MgbW9yZSBsaWtl IGEgdjZvcHMgZG9jdW1lbnQsIGFuZCBpdCBjb3VsZCBwcm9iYWJseSBiZSByZW5hbWVkIHRvIG1h dGNoIHRoYXQgZW1waGFzaXMuDQogJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaW08L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_26DE8EFEABA94754BBD1B9651797DDC0jiscacuk_-- From nobody Tue Jan 3 12:13:08 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED37C129B70; Tue, 3 Jan 2017 12:13:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 BxwRFdu8wsHK; Tue, 3 Jan 2017 12:13:02 -0800 (PST) Received: from mail-qk0-x243.google.com (mail-qk0-x243.google.com [IPv6:2607:f8b0:400d:c09::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F868129B4B; Tue, 3 Jan 2017 12:13:02 -0800 (PST) Received: by mail-qk0-x243.google.com with SMTP id u25so51316007qki.2; Tue, 03 Jan 2017 12:13:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=ftJxlfpXa51Y0RON3WGo9YWQmzSzpfhFQllJ16aCcOs=; b=ZgfnkYlEEw95Dk504ye4omQWpewN6Ye2ftJMDS1MWPrnlezcZPtBbg8/5iAV01rAeL H52CXAcbdjbHHgsxiT0r258X+wxtchwnSv2ZyKAI6ODdAUZt0pdsrmgr352Yz+CGZ3mo u0ApUT0nc3MgS1epgHJ7AkLOjJqzPd9i9y7mH/tgppfUqm9wzodIcoKFRb238WxSGnQF dgKUh2BVY29kA5vkBeQG6yPGIYhdrY1O/23PbmUYemfL23J/+WN/O8MeuhNwrv1cLYnI p05xVQyFoeAWkYgxZFA8tSqeMDa/qcN2XEYjdqL7Ra/s0iOu+fHM/mvqh7w6R8l4RNwt 8AEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=ftJxlfpXa51Y0RON3WGo9YWQmzSzpfhFQllJ16aCcOs=; b=RfgSWLr1wCeV38s5I9FdG9WwYY9T1my9rhXaSIRbTI5u+3VuMKntB5+8uohDH/Csdo oRxu7s3EqIOFnzqbQzVVDtD/M/uDYQ376RpLlFSWA7xAk3b/Euq/WuzcK57AYUukDHnQ Msk3ZrduWWYfUo0i7vWmC3Mq8diOKhEzH5i0CrC6O8ixy6CVkDrR1IAQ8hkMMfHCOfWg WRuKcSLMFcZL3RE0c/5rZHS8UJb8GnCEzIF62DXFUFTfVEgEQkABNKAZeW0aTiByUpEu BTPaw0RZ8viUoWqIKYfYtEgejcUA5wG6Tdq5ClepgyYYFFrNu7d5T3kp2ZlbdxsRBoGz ZVuQ== X-Gm-Message-State: AIkVDXKd7bxrYXnzZKHjC6cAuAwuGoy7FdyfPgU7xtWEJTJnWU0IZZ3RISw6ntvkb9Qmuw== X-Received: by 10.55.169.21 with SMTP id s21mr62407957qke.246.1483474381479; Tue, 03 Jan 2017 12:13:01 -0800 (PST) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id a81sm44353713qkg.28.2017.01.03.12.12.59 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 03 Jan 2017 12:13:00 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_92DA8041-F632-487F-A88B-CC6D95AD36D1"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Bob Hinden In-Reply-To: <9A4806E3-70B8-46E7-921D-4BA0817B16C7@gmail.com> Date: Tue, 3 Jan 2017 12:12:57 -0800 Message-Id: <4EC5F276-BD8D-4169-82AB-F0E0225A04AE@gmail.com> References: <027a01d262e7$f30b30d0$d9219270$@riw.us> <9A4806E3-70B8-46E7-921D-4BA0817B16C7@gmail.com> To: Fred Baker X-Mailer: Apple Mail (2.2104) Archived-At: Cc: v6ops list , IPv6 List , Russ White , draft-ali-ipv6rtr-reqs@tools.ietf.org Subject: Re: [v6ops] Comments on draft-ali-ipv6rtr-reqs-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 20:13:04 -0000 --Apple-Mail=_92DA8041-F632-487F-A88B-CC6D95AD36D1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Fred. > On Jan 1, 2017, at 5:23 PM, Fred Baker = wrote: >=20 >=20 >> On Dec 30, 2016, at 1:59 PM, Russ White wrote: >>=20 >>=20 >>> It is indeed an individual draft, and to my knowledge no given = working >> group >>> has been asked for opinions. That said, we welcome any and all = review. >>> Specifically, I have copied v6ops and 6man on this note. >>=20 >> We would like to present it to a WG as a work item--which WG would be = best >> for this one? There are some sections that need to be filled before = we >> present it, I think. >>=20 >> :-) >>=20 >> Russ >=20 > Personaly opinion: this isn=E2=80=99t about IPv6 per se, it is about = the operation of an IPv6 network. I=E2=80=99d suggest v6ops. Probably good to keep both w.g.=E2=80=99s involved. I was thinking this = was similar to IPv6 Node Requirements which in in 6MAN. Also, 6MAN has started on an Node Requirements bis document, good to = keep this coordinated with that. Bob >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail=_92DA8041-F632-487F-A88B-CC6D95AD36D1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJYbAXKAAoJEK7rdBF357uoDqIH/jWnPRNDX1JIYJJLMCITi7Qa TvajR0uJAj0h7yfj1+GBNTImQhMM0t6IlwnX41gkJas1nko3Y1Zduibi4RRxveun 1vKChJETnUorNWrSUU4pxg7DJeNXYvm9P44+1bn2h8TH7XLbWD2AbNtjN7fSyqjY N1wG5AoqZmXZPYvkBUdiqC2JgwzTfi8EL7ZF3+p3LU+p50ODgA5oHVkQMQatusil sM0n/CMaV77TaD3QKThXvKCjxZE31yYssNHFnkIzrt2Te8kg6eush7odzYFk8N6G Kmugw5lcMai0OEv5EcBOumrgD0yoWcNbJKivClW/K9S+WYNWrTO8DFRYAE6/WL0= =8+Eb -----END PGP SIGNATURE----- --Apple-Mail=_92DA8041-F632-487F-A88B-CC6D95AD36D1-- From nobody Tue Jan 3 12:51:50 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8D941296E7; Tue, 3 Jan 2017 12:51:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 E1WemiL8O4hK; Tue, 3 Jan 2017 12:51:46 -0800 (PST) Received: from mail-pg0-x241.google.com (mail-pg0-x241.google.com [IPv6:2607:f8b0:400e:c05::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC854129690; Tue, 3 Jan 2017 12:51:46 -0800 (PST) Received: by mail-pg0-x241.google.com with SMTP id b1so34591022pgc.1; Tue, 03 Jan 2017 12:51:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=hu85ECO8IQfHvEvy48R3wesZOVBnaOJefRgafTCPdaI=; b=Psv6/uTzAr19mcFa+3TbRWuDnuwGaYc/G0gS0Tbe10on9NWgpGABLBWnLg27Ur09uw BTLwqY+TmTdoE4OiGyHjVEiAc0X/pPT5xWigELei1m++RoMfOVFGQsRTV54QpNNPAPsY gDzZSl/80yC4L57n2RLsS9v0uyhfxvJHcFxjDyKvCXmjK4s6k3pR4SVqynEt5cC6rMbr FpETAs5+G5550uFpRlcPWYGQgUYiHJXFGzlbjS1mgTQMrEnVT6pnVa8cVuxNHEX6E9bF 4NxCtHQiyHR6rtE+FwyEAKy7nDkUu6RKJnlORJCaRI/15pm4Hk+HALNLht+Pi2JWp/zB Gnkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=hu85ECO8IQfHvEvy48R3wesZOVBnaOJefRgafTCPdaI=; b=g8OMvM6qhc0dEVFGEC7E2jlJ5WMFuSH97Sd27ieTlwPF9q5uCDjam2biAN2+6OxGFL bU98tlqj8j04kRtwsDhbpwuRFKRvyn6aQiAbu8ONzlepB8L1KY2tmnsEKeKGcZktrih2 WkvHzOP4haDy7mtVk0Z0JjzolAg7X4TEziflFfy2iUlDhSK7TgqGAxjxy8VJqPWP57Q+ r1RgESN9WhARxuEzxfoH8e1bztQY45CHt26MfvPB6xFUBtPz+K5Q08+58m//SmVCOMPF 9Dj5zHfM4gTULI47+055mrQoeRWuovzfvAwO08MAy+aus+2vIfLuC+LGoyFUXY1mvRJG gOqw== X-Gm-Message-State: AIkVDXJ+u9lEM8rVz9PXUq3Vq0Wf00srNuq4VYLTIl2xVQsAzkM5KCqH6RiOZHX3aykvLQ== X-Received: by 10.99.153.26 with SMTP id d26mr120073598pge.44.1483476706462; Tue, 03 Jan 2017 12:51:46 -0800 (PST) Received: from [192.168.1.2] (wsip-184-191-158-59.sd.sd.cox.net. [184.191.158.59]) by smtp.gmail.com with ESMTPSA id p14sm141931351pfl.74.2017.01.03.12.51.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Jan 2017 12:51:45 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Fred Baker In-Reply-To: <4EC5F276-BD8D-4169-82AB-F0E0225A04AE@gmail.com> Date: Tue, 3 Jan 2017 12:51:43 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <3CB761D0-9073-4FCE-A504-AD7941606A0E@gmail.com> References: <027a01d262e7$f30b30d0$d9219270$@riw.us> <9A4806E3-70B8-46E7-921D-4BA0817B16C7@gmail.com> <4EC5F276-BD8D-4169-82AB-F0E0225A04AE@gmail.com> To: Bob Hinden X-Mailer: Apple Mail (2.3259) Archived-At: Cc: Russ White , draft-ali-ipv6rtr-reqs@tools.ietf.org, IPv6 List , v6ops list Subject: Re: [v6ops] Comments on draft-ali-ipv6rtr-reqs-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 20:51:49 -0000 No argument, and BTW I tend to think most documents in both working = groups benefit from cross-pollination :-) > On Jan 3, 2017, at 12:12 PM, Bob Hinden wrote: >=20 > Fred. >=20 >> On Jan 1, 2017, at 5:23 PM, Fred Baker = wrote: >>=20 >>=20 >>> On Dec 30, 2016, at 1:59 PM, Russ White wrote: >>>=20 >>>=20 >>>> It is indeed an individual draft, and to my knowledge no given = working >>> group >>>> has been asked for opinions. That said, we welcome any and all = review. >>>> Specifically, I have copied v6ops and 6man on this note. >>>=20 >>> We would like to present it to a WG as a work item--which WG would = be best >>> for this one? There are some sections that need to be filled before = we >>> present it, I think. >>>=20 >>> :-) >>>=20 >>> Russ >>=20 >> Personaly opinion: this isn=E2=80=99t about IPv6 per se, it is about = the operation of an IPv6 network. I=E2=80=99d suggest v6ops. >=20 > Probably good to keep both w.g.=E2=80=99s involved. I was thinking = this was similar to IPv6 Node Requirements which in in 6MAN. >=20 > Also, 6MAN has started on an Node Requirements bis document, good to = keep this coordinated with that. >=20 > Bob >=20 >=20 >=20 >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >=20 From nobody Tue Jan 3 19:38:01 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FFA81279EB for ; Tue, 3 Jan 2017 19:38:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 kX2T619euE8p for ; Tue, 3 Jan 2017 19:37:58 -0800 (PST) Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A58D4126BF6 for ; Tue, 3 Jan 2017 19:37:58 -0800 (PST) Received: by mail-pg0-x22c.google.com with SMTP id g1so182837400pgn.0 for ; Tue, 03 Jan 2017 19:37:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=drmsLWxeEnB/dMuRWvxJ7pQ9dTORAIXN07YPjeDIAw0=; b=tRjISvw31otAvTcKZTa95nSd8clvNsE8+CClAmZkD4HQm90ZGVwuhQyFqQ717+NXkm KLklhurEfMiHPOiXmu/axlKhopxfAweDD+xFZao0wDj1OC3CuJGlzVMpyQG6S/W/ofsS bnhQ4VnFBZrLPcWvN92xW3MW/c9+UaC47gMrPv2UJKC483StZRmTxZMOEtJ4JMzPeYp4 HPx1R/FN87gOHOqtV0bii+K/yJUUNYUQyOCPi7LaKhD/dCylByYsee75A6BEkDUm4WFG Ey3qmS9bo/loR/aJzHIp48r28Be8rHnVpNilhaGELLbRgMJmuQrK93i4AM8FQIz2sfED SX/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=drmsLWxeEnB/dMuRWvxJ7pQ9dTORAIXN07YPjeDIAw0=; b=ms2s/R24VCPcXYsAJxlA+cSDOjSeDWbZpLVpygD8cdnyl6zngazfrv6fMwlaxziiQV rHhCtKeo3WVfWYGSY2RwbFC9sxeRJyor5dPYiZVddn2j/YM2FRU+gK5SqoBXEg97hQky OuDBylet90htQzhPiud2afmMJR+eNgiIIUAT2t488/jVV2IhuXD4LO/ujFPPwyriyHyk UpiHBFTiiTzMd7luqTTyKcVdwPnc/MJDg+4hwEb4aeOqTeZ4OHhU614kpp5S/uewEoyl p89T27lmmguyDU/x8LqAw+qIVwnEyJYYfxnUaO/zKxLlgUxxkGBzuNiyUqolmmCTKhWi PZHQ== X-Gm-Message-State: AIkVDXKtXv89LrxWxnOULXddWgeMsnzOMCj7fJyd6TJ47l3ZilymyFQcRqAzHRvIA3Xuxg== X-Received: by 10.84.173.195 with SMTP id p61mr141492149plb.158.1483501078266; Tue, 03 Jan 2017 19:37:58 -0800 (PST) Received: from [192.168.1.2] (wsip-184-191-158-59.sd.sd.cox.net. [184.191.158.59]) by smtp.gmail.com with ESMTPSA id z19sm41726104pfi.87.2017.01.03.19.37.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Jan 2017 19:37:57 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Fred Baker In-Reply-To: Date: Tue, 3 Jan 2017 19:37:56 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7449180F-C468-46BC-B5ED-CB9D3B97E7A6@gmail.com> References: <6cc8fa42-cb66-816b-f000-3635cde9cc90@gmail.com> <651319E6-BF0B-4700-B875-EA77440EB2C4@gmail.com> <09a4f40a-e996-df5f-23cb-771d1ac144c5@bogus.com> To: "Asveren, Tolga" X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] RFC6555 / Multiple interfaces X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 03:38:00 -0000 I worry about the implementation of the musts and shoulds. How does a = random application, that doesn't necessarily know much about the OS or = hardware underneath it, know whether two addresses are on the same or = different interfaces? Yes, there are platforms in which they do. That's = not "all platforms", not by a long shot. Personally, I would focus on ensuring that the problem is describable, = repeatable, and real before working on, or embellishing, a solution. = With HE, there was a real problem - dual stack systems sometimes = (demonstrably) waited for amazingly long times (anecdotal evidence says = there were cases up to half an hour) before a TCP time-out occurred, = making such platforms difficult for a real user to depend on without = turning IPv6 off. HE is far from a perfect solution, but it turns out to = be enough of a solution that the original problem isn't very real now.=20= Tell me about the problem you're trying to solve. What are the symptoms? = Is it reproducible? Who is feeling pain? How do we know when we have = solved it? > On Jan 3, 2017, at 3:58 AM, Asveren, Tolga = wrote: >=20 > Maybe a two-step approach? >=20 > i- "Entities following procedures in RFC6555 SHOULD perform connection = checks for each interface in parallel, if an IP Address Family can = utilize more than one interface. While doing so, they MAY consider other = factor and parameters, e.g. a priori knowledge about user preferences = for particular applications, interface capabilities." >=20 > IMHO this should be stated in a "Standards Track" specification. >=20 > ii- Other specifications, probably all/mostly "Informational", = providing recommendations about Socket API usage, interface type = specific procedures etc... >=20 > Would such a split make sense? I know i- could be considered as "too = little/no brainer" but that arguably may be true for RFC6555 in general = -especailly the "obviousness"-. >=20 > Thanks, > Tolga >=20 >> -----Original Message----- >> From: Fred Baker [mailto:fredbaker.ietf@gmail.com] >> Sent: Monday, January 02, 2017 7:39 PM >> To: joel jaeggli >> Cc: Asveren, Tolga ; v6ops@ietf.org >> Subject: Re: [v6ops] RFC6555 / Multiple interfaces >>=20 >>=20 >>> On Jan 2, 2017, at 3:12 PM, joel jaeggli wrote: >>>=20 >>> I wonder whether this can be formulated as a nice tight algorithm or >>> if this is just a set of heuristics that need to be incompletely >>> applied depending on your use case. >>=20 >> Probably that. >=20 From nobody Tue Jan 3 20:57:42 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 392E5129536; Tue, 3 Jan 2017 20:57:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.852 X-Spam-Level: X-Spam-Status: No, score=-0.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=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 cfILVOFbFMJU; Tue, 3 Jan 2017 20:57:35 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8789C12952E; Tue, 3 Jan 2017 20:57:35 -0800 (PST) Received: from [192.168.3.88] (142-135-17-190.fibertel.com.ar [190.17.135.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 3B249838DB; Wed, 4 Jan 2017 05:57:26 +0100 (CET) To: Fred Baker , Russ White References: <027a01d262e7$f30b30d0$d9219270$@riw.us> <9A4806E3-70B8-46E7-921D-4BA0817B16C7@gmail.com> <88D7C907-1BD2-40E7-9DEA-5BAF42688046@gmail.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <245a034f-1e15-2556-c39e-f950bea5263f@si6networks.com> Date: Tue, 3 Jan 2017 03:07:38 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <88D7C907-1BD2-40E7-9DEA-5BAF42688046@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-ali-ipv6rtr-reqs@tools.ietf.org, 6man WG , v6ops list Subject: Re: [v6ops] Comments on draft-ali-ipv6rtr-reqs-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 04:57:37 -0000 On 01/01/2017 10:26 PM, Fred Baker wrote: > >> On Jan 1, 2017, at 5:23 PM, Fred Baker >> wrote: >> >> >>> On Dec 30, 2016, at 1:59 PM, Russ White wrote: >>> >>> >>>> It is indeed an individual draft, and to my knowledge no given >>>> working >>> group >>>> has been asked for opinions. That said, we welcome any and all >>>> review. Specifically, I have copied v6ops and 6man on this >>>> note. >>> >>> We would like to present it to a WG as a work item--which WG >>> would be best for this one? There are some sections that need to >>> be filled before we present it, I think. >>> >>> :-) >>> >>> Russ >> >> Personaly opinion: this isn’t about IPv6 per se, it is about the >> operation of an IPv6 network. I’d suggest v6ops. > > Note that I’m not precluding 6man input. I’m asking what change or > clarification in IPv6 implementations (e.g., IPv6 Maintenance) is > called for. I don’t think there are any. I think it comments on how > IPv6 is used operationally, and by extension, what an operator might > expect to find in IPv6 implementations he deploys. I somewhat agree, but: wasn't the Node Requirements RFC produced by 6man? -- this one should be similar in nature... Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Jan 4 00:07:23 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B81D12940E; Wed, 4 Jan 2017 00:07:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10 X-Spam-Level: X-Spam-Status: No, score=-10 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1] autolearn=ham autolearn_force=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 NSexkrOMapVR; Wed, 4 Jan 2017 00:07:16 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0876128E19; Wed, 4 Jan 2017 00:07:16 -0800 (PST) Received: from mbp-4.local ([IPv6:2607:fb90:80a2:cb36:fcfd:2be3:e77e:6987]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id v0487CHo076522 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 4 Jan 2017 08:07:13 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host [IPv6:2607:fb90:80a2:cb36:fcfd:2be3:e77e:6987] claimed to be mbp-4.local To: Fernando Gont , Fred Baker , Russ White References: <027a01d262e7$f30b30d0$d9219270$@riw.us> <9A4806E3-70B8-46E7-921D-4BA0817B16C7@gmail.com> <88D7C907-1BD2-40E7-9DEA-5BAF42688046@gmail.com> <245a034f-1e15-2556-c39e-f950bea5263f@si6networks.com> From: joel jaeggli Message-ID: <43943ea7-6ae2-91f0-9518-a3c61fcb0a22@bogus.com> Date: Wed, 4 Jan 2017 00:07:11 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:50.0) Gecko/20100101 Thunderbird/50.0 MIME-Version: 1.0 In-Reply-To: <245a034f-1e15-2556-c39e-f950bea5263f@si6networks.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RvBCQNpG5R7SAsBHpsm2Mj7lCxqO5PaDB" Archived-At: Cc: draft-ali-ipv6rtr-reqs@tools.ietf.org, 6man WG , v6ops list Subject: Re: [v6ops] Comments on draft-ali-ipv6rtr-reqs-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 08:07:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --RvBCQNpG5R7SAsBHpsm2Mj7lCxqO5PaDB Content-Type: multipart/mixed; boundary="CAC0OwNDRPS8K3S8Me8rm5S7O50w96QJl"; protected-headers="v1" From: joel jaeggli To: Fernando Gont , Fred Baker , Russ White Cc: Mohammad Moghaddas , draft-ali-ipv6rtr-reqs@tools.ietf.org, 6man WG , v6ops list Message-ID: <43943ea7-6ae2-91f0-9518-a3c61fcb0a22@bogus.com> Subject: Re: [v6ops] Comments on draft-ali-ipv6rtr-reqs-01 References: <027a01d262e7$f30b30d0$d9219270$@riw.us> <9A4806E3-70B8-46E7-921D-4BA0817B16C7@gmail.com> <88D7C907-1BD2-40E7-9DEA-5BAF42688046@gmail.com> <245a034f-1e15-2556-c39e-f950bea5263f@si6networks.com> In-Reply-To: <245a034f-1e15-2556-c39e-f950bea5263f@si6networks.com> --CAC0OwNDRPS8K3S8Me8rm5S7O50w96QJl Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US On 1/2/17 10:07 PM, Fernando Gont wrote: > On 01/01/2017 10:26 PM, Fred Baker wrote: >>> On Jan 1, 2017, at 5:23 PM, Fred Baker >>> wrote: >>> >>> >>>> On Dec 30, 2016, at 1:59 PM, Russ White wrote: >>>> >>>> >>>>> It is indeed an individual draft, and to my knowledge no given >>>>> working >>>> group >>>>> has been asked for opinions. That said, we welcome any and all >>>>> review. Specifically, I have copied v6ops and 6man on this >>>>> note. >>>> We would like to present it to a WG as a work item--which WG >>>> would be best for this one? There are some sections that need to >>>> be filled before we present it, I think. >>>> >>>> :-) >>>> >>>> Russ >>> Personaly opinion: this isn=E2=80=99t about IPv6 per se, it is about = the >>> operation of an IPv6 network. I=E2=80=99d suggest v6ops. >> Note that I=E2=80=99m not precluding 6man input. I=E2=80=99m asking wh= at change or >> clarification in IPv6 implementations (e.g., IPv6 Maintenance) is >> called for. I don=E2=80=99t think there are any. I think it comments o= n how >> IPv6 is used operationally, and by extension, what an operator might >> expect to find in IPv6 implementations he deploys. > I somewhat agree, but: wasn't the Node Requirements RFC produced by > 6man? -- this one should be similar in nature... and 6204 / 7084 / 7849 were done in v6ops, it's not that unusual a style of document generally speaking. > > Thanks, --CAC0OwNDRPS8K3S8Me8rm5S7O50w96QJl-- --RvBCQNpG5R7SAsBHpsm2Mj7lCxqO5PaDB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlhsrTAACgkQ8AA1q7Z/VrIm+ACfa/duZuCzc7HyDEWoCYV/6BFM h2AAoID6D1OU0gWzNBaI0dNjGPkZmCH3 =9/5y -----END PGP SIGNATURE----- --RvBCQNpG5R7SAsBHpsm2Mj7lCxqO5PaDB-- From nobody Wed Jan 4 00:47:47 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C782129C49 for ; Wed, 4 Jan 2017 00:47:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.09 X-Spam-Level: X-Spam-Status: No, score=-4.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=jisc365.onmicrosoft.com 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 5K5Ehyt2njPx for ; Wed, 4 Jan 2017 00:47:43 -0800 (PST) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DE341294A4 for ; Wed, 4 Jan 2017 00:47:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc365.onmicrosoft.com; s=selector1-jisc-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=dcKlJuifF7zlAkqCsqSRfaO/AkMz+BTalbcx0wozzzk=; b=ThnXSqct4bkbNZn10j92fHo1o5ZjPtGeI/pMYyOT0iAOLiENxwfur+KaM6mcucDfLCevEx8R6sw93h3e/jrgRezf8nHY7SW4O4RrjOh1l5xjq277pf8d4s3E6hnASHz/uuFCbr+hLBVvcYtE5IyKbwWyQ/j8unGWzgYweTnSN5o= Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-am5eur03lp0120.outbound.protection.outlook.com [213.199.154.120]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-34-_xUCUYLMNoi_wjdk4oCXFA-1; Wed, 04 Jan 2017 08:47:35 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1139.eurprd07.prod.outlook.com (10.163.188.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.829.4; Wed, 4 Jan 2017 08:47:34 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::292e:d46e:7c2b:75c6]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::292e:d46e:7c2b:75c6%15]) with mapi id 15.01.0829.003; Wed, 4 Jan 2017 08:47:34 +0000 From: Tim Chown To: joel jaeggli Thread-Topic: [v6ops] Comments on draft-ali-ipv6rtr-reqs-01 Thread-Index: AQHSYUSKP4RyXDRcfEW58qB9cBducaEd5l2AgAMk2QCAAAIlgIADXd2AgAAA0wCAAeDKAIABs7uAgAALSQA= Date: Wed, 4 Jan 2017 08:47:34 +0000 Message-ID: <280F2FFC-E778-4A0C-B4A7-7AF215588A8A@jisc.ac.uk> References: <027a01d262e7$f30b30d0$d9219270$@riw.us> <9A4806E3-70B8-46E7-921D-4BA0817B16C7@gmail.com> <88D7C907-1BD2-40E7-9DEA-5BAF42688046@gmail.com> <245a034f-1e15-2556-c39e-f950bea5263f@si6networks.com> <43943ea7-6ae2-91f0-9518-a3c61fcb0a22@bogus.com> In-Reply-To: <43943ea7-6ae2-91f0-9518-a3c61fcb0a22@bogus.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3259) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [194.82.140.195] x-ms-office365-filtering-correlation-id: a256b3a3-df59-4661-c8ff-08d4347e53da x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:AM3PR07MB1139; x-microsoft-exchange-diagnostics: 1; AM3PR07MB1139; 7:XuvV/0uR3mZNv+mY7cG/ALOevcbqO2/LbCBJFqxLYZlQcwgjbyt3neR8RNADmdi0IrqqkPceGzZN27CF/uPCba9QzQJeT7bywgQxKFB29CsF3Xs5eQtw5MUesBdSGzCwZsYLJBMY63SEfeac7RuL8gQVt5t0pPT6poaOWKjKks5qV9UwxXV6taYeEIyHN3/Gb34d5fVWEigEn6R9yQN237KmRiksbf25c/P68UaJacGs/WQSfq4CfhJ5J0lOnL+9J6wdtAcvb9gVG7tREiJBeZDMnpFrs1iDMkfuaRonr/nd8FWEKQG9Deta62wyKimlfxmhcsAeRNLPZLaoNlLcraebA4qcA3Wcl87fdqDCvT81GFOgCm8A0uzSRI1AIEi93WP48IzzEmoncv9jSRMwty1cnZZS3ldcvh2KwiFHq7S4QvbKLZObBQQh/1Mwl3115FLg4bBL4teq3jm6c4laZw==; 20:hK0eATqh6znZyWqCqKX0u2Wi3f0lpWLV6NgBEkc/1iSdaF9EDjIpKNN2PQtX8G/rjNpv7F5KwiV4Fk4HS6ZjFpGtxAsU7pbLUzHoRaz1JLmvq7sTFYH8VntcSe31xazRHn1B4ks/xstV3jZ0XGR8+7SLUTVMMFYM6dLWCIa6KCY= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6072148); SRVR:AM3PR07MB1139; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1139; x-forefront-prvs: 0177904E6B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(39450400003)(24454002)(199003)(377454003)(189002)(92566002)(38730400001)(6512006)(6506006)(39060400001)(6436002)(68736007)(189998001)(5660300001)(36756003)(3280700002)(229853002)(97736004)(57306001)(42882006)(6916009)(110136003)(2950100002)(4326007)(83716003)(99286003)(5250100002)(2906002)(66066001)(106356001)(106116001)(82746002)(54906002)(74482002)(230783001)(8936002)(7736002)(8676002)(102836003)(81156014)(81166006)(93886004)(105586002)(6116002)(50986999)(86362001)(76176999)(33656002)(3660700001)(101416001)(2900100001)(6486002)(3846002)(50226002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1139; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jan 2017 08:47:34.2232 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1139 X-MC-Unique: _xUCUYLMNoi_wjdk4oCXFA-1 Content-Type: multipart/alternative; boundary="_000_280F2FFCE7784A0CB4A77AF215588A8Ajiscacuk_" Archived-At: Cc: v6ops list , 6man WG , Russ White , "draft-ali-ipv6rtr-reqs@tools.ietf.org" , Fernando Gont Subject: Re: [v6ops] Comments on draft-ali-ipv6rtr-reqs-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 08:47:45 -0000 --_000_280F2FFCE7784A0CB4A77AF215588A8Ajiscacuk_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 T24gNCBKYW4gMjAxNywgYXQgMDg6MDcsIGpvZWwgamFlZ2dsaSA8am9lbGphQGJvZ3VzLmNvbTxt YWlsdG86am9lbGphQGJvZ3VzLmNvbT4+IHdyb3RlOg0KDQpPbiAxLzIvMTcgMTA6MDcgUE0sIEZl cm5hbmRvIEdvbnQgd3JvdGU6DQpPbiAwMS8wMS8yMDE3IDEwOjI2IFBNLCBGcmVkIEJha2VyIHdy b3RlOg0KT24gSmFuIDEsIDIwMTcsIGF0IDU6MjMgUE0sIEZyZWQgQmFrZXIgPGZyZWRiYWtlci5p ZXRmQGdtYWlsLmNvbTxtYWlsdG86ZnJlZGJha2VyLmlldGZAZ21haWwuY29tPj4NCndyb3RlOg0K DQoNCk9uIERlYyAzMCwgMjAxNiwgYXQgMTo1OSBQTSwgUnVzcyBXaGl0ZSA8cnVzc0ByaXcudXM8 bWFpbHRvOnJ1c3NAcml3LnVzPj4gd3JvdGU6DQoNCg0KSXQgaXMgaW5kZWVkIGFuIGluZGl2aWR1 YWwgZHJhZnQsIGFuZCB0byBteSBrbm93bGVkZ2Ugbm8gZ2l2ZW4NCndvcmtpbmcNCmdyb3VwDQpo YXMgYmVlbiBhc2tlZCBmb3Igb3BpbmlvbnMuIFRoYXQgc2FpZCwgd2Ugd2VsY29tZSBhbnkgYW5k IGFsbA0KcmV2aWV3LiBTcGVjaWZpY2FsbHksIEkgaGF2ZSBjb3BpZWQgdjZvcHMgYW5kIDZtYW4g b24gdGhpcw0Kbm90ZS4NCldlIHdvdWxkIGxpa2UgdG8gcHJlc2VudCBpdCB0byBhIFdHIGFzIGEg d29yayBpdGVtLS13aGljaCBXRw0Kd291bGQgYmUgYmVzdCBmb3IgdGhpcyBvbmU/IFRoZXJlIGFy ZSBzb21lIHNlY3Rpb25zIHRoYXQgbmVlZCB0bw0KYmUgZmlsbGVkIGJlZm9yZSB3ZSBwcmVzZW50 IGl0LCBJIHRoaW5rLg0KDQo6LSkNCg0KUnVzcw0KUGVyc29uYWx5IG9waW5pb246IHRoaXMgaXNu 4oCZdCBhYm91dCBJUHY2IHBlciBzZSwgaXQgaXMgYWJvdXQgdGhlDQpvcGVyYXRpb24gb2YgYW4g SVB2NiBuZXR3b3JrLiBJ4oCZZCBzdWdnZXN0IHY2b3BzLg0KTm90ZSB0aGF0IEnigJltIG5vdCBw cmVjbHVkaW5nIDZtYW4gaW5wdXQuIEnigJltIGFza2luZyB3aGF0IGNoYW5nZSBvcg0KY2xhcmlm aWNhdGlvbiBpbiBJUHY2IGltcGxlbWVudGF0aW9ucyAoZS5nLiwgSVB2NiBNYWludGVuYW5jZSkg aXMNCmNhbGxlZCBmb3IuIEkgZG9u4oCZdCB0aGluayB0aGVyZSBhcmUgYW55LiBJIHRoaW5rIGl0 IGNvbW1lbnRzIG9uIGhvdw0KSVB2NiBpcyB1c2VkIG9wZXJhdGlvbmFsbHksIGFuZCBieSBleHRl bnNpb24sIHdoYXQgYW4gb3BlcmF0b3IgbWlnaHQNCmV4cGVjdCB0byBmaW5kIGluIElQdjYgaW1w bGVtZW50YXRpb25zIGhlIGRlcGxveXMuDQpJIHNvbWV3aGF0IGFncmVlLCBidXQ6IHdhc24ndCB0 aGUgTm9kZSBSZXF1aXJlbWVudHMgUkZDIHByb2R1Y2VkIGJ5DQo2bWFuPyAtLSB0aGlzIG9uZSBz aG91bGQgYmUgc2ltaWxhciBpbiBuYXR1cmUuLi4NCmFuZCA2MjA0IC8gNzA4NCAvIDc4NDkgd2Vy ZSBkb25lIGluIHY2b3BzLCBpdCdzIG5vdCB0aGF0IHVudXN1YWwgYSBzdHlsZQ0Kb2YgZG9jdW1l bnQgZ2VuZXJhbGx5IHNwZWFraW5nLg0KDQpUaGlzIGRyYWZ0IGlzIGEgbGl0dGxlIGRpZmZlcmVu dCB0byBSRkM2NDM0OyB0aGVyZeKAmXMgbW9yZSBvcGVyYXRpb25hbC9kZXNpZ24gdGV4dCBpbiB0 aGVyZS4NCg0KVGhlIGltcG9ydGFudCB0aGluZyBpcyB0aGF0LCBnaXZlbiBpdCBsb29rcyBsaWtl IHJlYWxseSBuaWNlIHdvcmssIGl0IGdldHMgYWRvcHRlZCBzb21ld2hlcmUgOikNCg0KVGltDQo= --_000_280F2FFCE7784A0CB4A77AF215588A8Ajiscacuk_ Content-Type: text/html; charset=UTF-8 Content-ID: <9A47AC54E3C3084191FC74C2B4097D0B@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiA0IEphbiAyMDE3LCBhdCAwODow Nywgam9lbCBqYWVnZ2xpICZsdDs8YSBocmVmPSJtYWlsdG86am9lbGphQGJvZ3VzLmNvbSIgY2xh c3M9IiI+am9lbGphQGJvZ3VzLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJB cHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFs OyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXIt c3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1p bmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdp ZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6 IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+ T24NCiAxLzIvMTcgMTA6MDcgUE0sIEZlcm5hbmRvIEdvbnQgd3JvdGU6PC9zcGFuPjxiciBzdHls ZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBu b3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxl dHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0 ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1h bDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13 aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBzdHlsZT0iZm9u dC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7 IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1z cGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWlu ZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lk b3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBh dXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCk9uIDAxLzAx LzIwMTcgMTA6MjYgUE0sIEZyZWQgQmFrZXIgd3JvdGU6PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0i Ij5PbiBKYW4gMSwgMjAxNywgYXQgNToyMyBQTSwgRnJlZCBCYWtlciAmbHQ7PGEgaHJlZj0ibWFp bHRvOmZyZWRiYWtlci5pZXRmQGdtYWlsLmNvbSIgY2xhc3M9IiI+ZnJlZGJha2VyLmlldGZAZ21h aWwuY29tPC9hPiZndDs8YnIgY2xhc3M9IiI+DQp3cm90ZTo8YnIgY2xhc3M9IiI+DQo8YnIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5P biBEZWMgMzAsIDIwMTYsIGF0IDE6NTkgUE0sIFJ1c3MgV2hpdGUgJmx0OzxhIGhyZWY9Im1haWx0 bzpydXNzQHJpdy51cyIgY2xhc3M9IiI+cnVzc0ByaXcudXM8L2E+Jmd0OyB3cm90ZTo8YnIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJj aXRlIiBjbGFzcz0iIj5JdCBpcyBpbmRlZWQgYW4gaW5kaXZpZHVhbCBkcmFmdCwgYW5kIHRvIG15 IGtub3dsZWRnZSBubyBnaXZlbjxiciBjbGFzcz0iIj4NCndvcmtpbmc8YnIgY2xhc3M9IiI+DQo8 L2Jsb2NrcXVvdGU+DQpncm91cDxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi IGNsYXNzPSIiPmhhcyBiZWVuIGFza2VkIGZvciBvcGluaW9ucy4gVGhhdCBzYWlkLCB3ZSB3ZWxj b21lIGFueSBhbmQgYWxsPGJyIGNsYXNzPSIiPg0KcmV2aWV3LiBTcGVjaWZpY2FsbHksIEkgaGF2 ZSBjb3BpZWQgdjZvcHMgYW5kIDZtYW4gb24gdGhpczxiciBjbGFzcz0iIj4NCm5vdGUuPGJyIGNs YXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KV2Ugd291bGQgbGlrZSB0byBwcmVzZW50IGl0IHRvIGEg V0cgYXMgYSB3b3JrIGl0ZW0tLXdoaWNoIFdHPGJyIGNsYXNzPSIiPg0Kd291bGQgYmUgYmVzdCBm b3IgdGhpcyBvbmU/IFRoZXJlIGFyZSBzb21lIHNlY3Rpb25zIHRoYXQgbmVlZCB0bzxiciBjbGFz cz0iIj4NCmJlIGZpbGxlZCBiZWZvcmUgd2UgcHJlc2VudCBpdCwgSSB0aGluay48YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQo6LSk8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpSdXNz PGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KUGVyc29uYWx5IG9waW5pb246IHRoaXMgaXNu 4oCZdCBhYm91dCBJUHY2IHBlciBzZSwgaXQgaXMgYWJvdXQgdGhlPGJyIGNsYXNzPSIiPg0Kb3Bl cmF0aW9uIG9mIGFuIElQdjYgbmV0d29yay4gSeKAmWQgc3VnZ2VzdCB2Nm9wcy48YnIgY2xhc3M9 IiI+DQo8L2Jsb2NrcXVvdGU+DQpOb3RlIHRoYXQgSeKAmW0gbm90IHByZWNsdWRpbmcgNm1hbiBp bnB1dC4gSeKAmW0gYXNraW5nIHdoYXQgY2hhbmdlIG9yPGJyIGNsYXNzPSIiPg0KY2xhcmlmaWNh dGlvbiBpbiBJUHY2IGltcGxlbWVudGF0aW9ucyAoZS5nLiwgSVB2NiBNYWludGVuYW5jZSkgaXM8 YnIgY2xhc3M9IiI+DQpjYWxsZWQgZm9yLiBJIGRvbuKAmXQgdGhpbmsgdGhlcmUgYXJlIGFueS4g SSB0aGluayBpdCBjb21tZW50cyBvbiBob3c8YnIgY2xhc3M9IiI+DQpJUHY2IGlzIHVzZWQgb3Bl cmF0aW9uYWxseSwgYW5kIGJ5IGV4dGVuc2lvbiwgd2hhdCBhbiBvcGVyYXRvciBtaWdodDxiciBj bGFzcz0iIj4NCmV4cGVjdCB0byBmaW5kIGluIElQdjYgaW1wbGVtZW50YXRpb25zIGhlIGRlcGxv eXMuPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KSSBzb21ld2hhdCBhZ3JlZSwgYnV0OiB3 YXNuJ3QgdGhlIE5vZGUgUmVxdWlyZW1lbnRzIFJGQyBwcm9kdWNlZCBieTxiciBjbGFzcz0iIj4N CjZtYW4/IC0tIHRoaXMgb25lIHNob3VsZCBiZSBzaW1pbGFyIGluIG5hdHVyZS4uLjxiciBjbGFz cz0iIj4NCjwvYmxvY2txdW90ZT4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNh OyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6 IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3Jw aGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJh bnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3Bh Y2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBk aXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPmFuZA0KIDYyMDQgLyA3MDg0IC8g Nzg0OSB3ZXJlIGRvbmUgaW4gdjZvcHMsIGl0J3Mgbm90IHRoYXQgdW51c3VhbCBhIHN0eWxlPC9z cGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBm b250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0 OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxp Z246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUt c3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10 ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQt dmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5n OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDog MHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBh dXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBm bG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5vZg0KIGRv Y3VtZW50IGdlbmVyYWxseSBzcGVha2luZy48L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTog SGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJp YW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5v cm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7 IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87 IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFz cz0iIj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2 IGNsYXNzPSIiPlRoaXMgZHJhZnQgaXMgYSBsaXR0bGUgZGlmZmVyZW50IHRvIFJGQzY0MzQ7IHRo ZXJl4oCZcyBtb3JlIG9wZXJhdGlvbmFsL2Rlc2lnbiB0ZXh0IGluIHRoZXJlLjwvZGl2Pg0KPGRp diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhlIGltcG9y dGFudCB0aGluZyBpcyB0aGF0LCBnaXZlbiBpdCBsb29rcyBsaWtlIHJlYWxseSBuaWNlIHdvcmss IGl0IGdldHMgYWRvcHRlZCBzb21ld2hlcmUgOik8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRpbTwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_280F2FFCE7784A0CB4A77AF215588A8Ajiscacuk_-- From nobody Thu Jan 5 00:43:45 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93FA512940D; Thu, 5 Jan 2017 00:43:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 i6SIm0HvPPLE; Thu, 5 Jan 2017 00:43:39 -0800 (PST) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50C9C1294B1; Thu, 5 Jan 2017 00:43:39 -0800 (PST) Received: by mail-yw0-x233.google.com with SMTP id t125so336558503ywc.1; Thu, 05 Jan 2017 00:43:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=EfwLPs1hptSc0tZGdbwjVA0/weOG8EQ7QZKC4UTtb8Y=; b=FoCGX+Jh3UDwxkkutwYvS6JZC73e/2zI92/gTtFiKun1Cx3bo2z8C/w5MajohkOl2Q CO92w2eFxt8Hfeu73FlPn5l3xeh2z0jQPcDVe1pes/6YQ0dsK4aWuPK2GUBPV2dAb+tB 6gMhK9W2KTMxyCAUbk7zGBUvFctCnRvEO9614OyOg6WtZmudp+ewZO0A1ZLw7PhcE8KU e2IwvgaoaDAmlp869PDPOviq6X4Ce3qxxhVOQMfQ3JXn0gvlzHCswU18vOZYJoYKorVH 2SDi5Gkz+NCYj4zCIWk0+CfMvznRHXftq3TopdArKpiuQFxdWjQYT8w8hhU246qIDD3A lBtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=EfwLPs1hptSc0tZGdbwjVA0/weOG8EQ7QZKC4UTtb8Y=; b=ABsR5vbXuaUEheJc/9k9/6lW5fdOb9QK19FVOrrTtCPrsQC9HjzDJeWcuJlW6fB5yY XMiUwgWwx83mCJxOsotG5bVCfTFO0rj064PRAg7iAXL8NLfCJWnSt+KGh4LiWAoBPdcH 0c3qOudQHioP3gGN5L1FtMHatzcfxKHcPP9didakuBugmObF4wbVfWS2rPo9oYDqVhF7 qB9ccAa/VvA42g+CvWI8xgMzWsUct1380IVw1nEA6gvf+2GQnvsqKpq/nokBihL2XzRH 6B2Lre4cBgMbByu8esT2N3xFDMz1/EIXWekmuA+0gay1ahx9u6c8u7sJS9eeXGPPP/tC 4PHA== X-Gm-Message-State: AIkVDXLCCJlS/v4tAzdPIPr4OAihrMXZAkQeKgewINIcvuvVbi3vFqFhiSMM0TXnBFITO63/1MzbGsNEAMMrOw== X-Received: by 10.129.119.7 with SMTP id s7mr73527774ywc.57.1483605818505; Thu, 05 Jan 2017 00:43:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.172.94 with HTTP; Thu, 5 Jan 2017 00:43:18 -0800 (PST) From: Naveen Kottapalli Date: Thu, 5 Jan 2017 14:13:18 +0530 Message-ID: To: 6man WG , v6ops list Content-Type: multipart/alternative; boundary=001a1149008ccc8547054554e580 Archived-At: Subject: [v6ops] Why is 0 UDP checksum not valid for IPv6? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 08:43:40 -0000 --001a1149008ccc8547054554e580 Content-Type: text/plain; charset=UTF-8 Hello, Can anyone tell why is 0 UDP checksum isn't valid for IPv6, whereas it is valid for IPv4? Yours, Naveen. --001a1149008ccc8547054554e580 Content-Type: text/html; charset=UTF-8
Hello,

Can anyone tell why is 0 UDP checksum isn't valid for IPv6, whereas it is valid for IPv4?

Yours,
Naveen.
--001a1149008ccc8547054554e580-- From nobody Thu Jan 5 01:33:02 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 688C2128E19; Thu, 5 Jan 2017 01:33:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.335 X-Spam-Level: X-Spam-Status: No, score=-1.335 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 BnZRY0-ejHa3; Thu, 5 Jan 2017 01:33:00 -0800 (PST) Received: from inbound03.kjsl.com (inbound03.kjsl.com [IPv6:2001:1868:a100:131::62]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE6A7129519; Thu, 5 Jan 2017 01:32:58 -0800 (PST) Received: from cowbell.employees.org ([IPv6:2001:1868:a000:17::142]) by ironport03.kjsl.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Jan 2017 09:32:57 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 5DD999CC7D; Thu, 5 Jan 2017 01:32:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s= selector1; bh=HnTzq2DikmtQkoZW+ndKW5bDTTY=; b=rkQu2w5j9e8JWTGBz8 ryj8Vi0GgecIhgif8NnLoAgY03kIGKEVzUAB5w08omcF823v6tyW3BrZ9Z/PiJpV FlCglccR7baK6V6xLfGkR85MLryjpbZB4KFD0QHfRmeyQzthZxjtXFEt1RPYxT3f lQghYxEbnqLGfwBQTmyeuDRIE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; q=dns; s= selector1; b=SkVwzl7bUPu2WtauM0oRvUfPU1fleAmFzstuELjNUfjeU/lTy85 IIMTAFEbJkdwzQ710ANG6eVFGRFBcg8OJxGtnf3fNxlU4ppot0AGzzOHipkLTuD8 KPLjV5Qo8rYqFCj6thYEV+QqxauXXhS64tIdQ2K9VWZe0oleWxBuD0yc= Received: from h.hanazo.no (2.150.57.252.tmi.telenormobil.no [2.150.57.252]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id A05369CC51; Thu, 5 Jan 2017 01:32:55 -0800 (PST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 5B9C5704D6ED; Thu, 5 Jan 2017 10:32:51 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: otroan@employees.org In-Reply-To: Date: Thu, 5 Jan 2017 10:32:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <48EECE17-E5F3-452A-88A3-DF1891466AEE@employees.org> References: To: Naveen Kottapalli X-Mailer: Apple Mail (2.3259) Archived-At: Cc: v6ops list , 6man WG Subject: Re: [v6ops] Why is 0 UDP checksum not valid for IPv6? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 09:33:01 -0000 Naveen, > Can anyone tell why is 0 UDP checksum isn't valid for IPv6, whereas it = is valid for IPv4? RFC6935 RFC6936 Cheers, Ole From nobody Thu Jan 5 02:08:23 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA74A129429; Thu, 5 Jan 2017 02:08:17 -0800 (PST) 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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 z8WblgC5wSJ6; Thu, 5 Jan 2017 02:08:16 -0800 (PST) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 903CE129423; Thu, 5 Jan 2017 02:08:16 -0800 (PST) Received: by mail-yw0-x229.google.com with SMTP id r204so338574735ywb.0; Thu, 05 Jan 2017 02:08:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=clpn3jSXfYLol3iOVlVP0VboV6FwYdJVBAsk23RZosM=; b=iwU4WwvCHJ4pCxZMLFZbipnYcyBXQd4xhh9B8Z+83IDzmoXNc6m/BO+1e7v3gs7amO t94fGNxxMR+vPcR3HenJcoEaXz+fDkQE0n6Xfm3w+MGVM5yI4GsujdoxS16DYIWUSCl5 Ms/wLf2AdzUiLwxMEG3KByAuh4lwOAXO8Unh60PUlZzgBWzpvgorxfwydW7dvHUj9gRp +tABvD2tE/hR/2ckQnr7SSUK5p76EBTrlp5bMxB6pd2lXBj5tVlt61jZaMJ64CiO5Dfw 9Amlg+kuPffSiUxeokOMKz3MFMDkMFAtN89I1LARpRtIlLwDFzoEJUAWL+nCYBKYgZ+Q TH/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=clpn3jSXfYLol3iOVlVP0VboV6FwYdJVBAsk23RZosM=; b=bvAuEVIOUOMLnC68ejWc57fuysB++el+yxuOH08TnMXRottb/ortWjvUXNY6VT+mLQ spvQouffy9WGgwXfN/GMODG6DGYsMo1wjPnSvpKCi1cgszfadCZgWMyx4oGomdkkb4wu DC7qGcpVL7/yNeP58Bldz+5P73V7fMsTWBUbgX33ST4uwOBiJTTv0T8lBctfPAFgtGSH AGPAwiQUIg15XadMp9dJuxZokJnMt5k7u1QBkdKQOcb2tl80LncbI9yLKr6z8DaWmdPr 2JWqJhc3V0I0w4VICie0XXn9Pyf/PzKpqLvTcHQWl9TqzlASyNnjknvhmh1FdV+eZi/U pkIw== X-Gm-Message-State: AIkVDXJB1NrYeAQCFkucyTxQZaijsZDtuvCy7R7frp1gL/MpnmoIALBszCwen83CEKL3662avrIFmrjLho7nTg== X-Received: by 10.13.202.73 with SMTP id m70mr61127957ywd.251.1483610895845; Thu, 05 Jan 2017 02:08:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.172.94 with HTTP; Thu, 5 Jan 2017 02:07:55 -0800 (PST) In-Reply-To: <48EECE17-E5F3-452A-88A3-DF1891466AEE@employees.org> References: <48EECE17-E5F3-452A-88A3-DF1891466AEE@employees.org> From: Naveen Kottapalli Date: Thu, 5 Jan 2017 15:37:55 +0530 Message-ID: To: otroan@employees.org Content-Type: multipart/alternative; boundary=001a114816606e912d05455614b4 Archived-At: Cc: v6ops list , 6man WG Subject: Re: [v6ops] Why is 0 UDP checksum not valid for IPv6? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 10:08:18 -0000 --001a114816606e912d05455614b4 Content-Type: text/plain; charset=UTF-8 I see those two RFCs talk mainly about the usage of UDP in tunneled protocols, but couldn't find why it is mandated for a normal plain IPv6 packet carrying a UDP payload with a DNS query or a response. In general am trying to find the reason why it is mandated in IPv6 base specification (RFC2460) itself. Can you please clarify on the above? Yours, Naveen. On 5 January 2017 at 15:02, wrote: > Naveen, > > > Can anyone tell why is 0 UDP checksum isn't valid for IPv6, whereas it > is valid for IPv4? > > RFC6935 > RFC6936 > > Cheers, > Ole > > --001a114816606e912d05455614b4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I see those two RFCs talk mainly about the usage of UDP in= tunneled protocols, but couldn't find why it is mandated for a normal = plain IPv6 packet carrying a UDP payload with a DNS query or a response.
In general am trying to find the reason why it is mandated= in IPv6 base specification (RFC2460) itself.

Can = you please clarify on the above?

Yours,
Naveen.

On 5 January 2017 at 15:02, <otroan@emp= loyees.org> wrote:
Naveen,<= br>
> Can anyone tell why is 0 UDP checksum isn't valid for IPv6, wherea= s it is valid for IPv4?

RFC6935
RFC6936

Cheers,
Ole


--001a114816606e912d05455614b4-- From nobody Thu Jan 5 02:11:09 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31BBA1294C0; Thu, 5 Jan 2017 02:11:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 FPLLt6foOCjS; Thu, 5 Jan 2017 02:11:05 -0800 (PST) Received: from smistad.uninett.no (smistad.uninett.no [IPv6:2001:700:1:0:eeb1:d7ff:fe59:fbaa]) by ietfa.amsl.com (Postfix) with ESMTP id 5702812949D; Thu, 5 Jan 2017 02:11:05 -0800 (PST) Received: from smistad.uninett.no (smistad.uninett.no [158.38.62.77]) by smistad.uninett.no (Postfix) with ESMTP id 15B2C43E9CB; Thu, 5 Jan 2017 11:11:03 +0100 (CET) Date: Thu, 05 Jan 2017 11:11:02 +0100 (CET) Message-Id: <20170105.111102.1073811603989045784.he@uninett.no> To: naveen.sarma@gmail.com From: Havard Eidnes In-Reply-To: References: <48EECE17-E5F3-452A-88A3-DF1891466AEE@employees.org> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: ipv6@ietf.org, v6ops@ietf.org Subject: Re: [v6ops] Why is 0 UDP checksum not valid for IPv6? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 10:11:07 -0000 >> > Can anyone tell why is 0 UDP checksum isn't valid for IPv6, wherea= s it >> > is valid for IPv4? >> >> RFC6935 >> RFC6936 > > I see those two RFCs talk mainly about the usage of UDP in tunneled > protocols, but couldn't find why it is mandated for a normal plain IP= v6 > packet carrying a UDP payload with a DNS query or a response. > = > In general am trying to find the reason why it is mandated in IPv6 ba= se > specification (RFC2460) itself. > = > Can you please clarify on the above? 6936 says: The key difference between UDP usage with IPv4 and IPv6 is that RFC 2460 mandates use of a calculated UDP checksum, i.e., a non-zero value, due to the lack of an IPv6 header checksum. Regards, - H=E5vard From nobody Thu Jan 5 02:20:10 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10B1F12950D; Thu, 5 Jan 2017 02:20:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 4pifa5jHZuV8; Thu, 5 Jan 2017 02:20:02 -0800 (PST) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9940612949A; Thu, 5 Jan 2017 02:20:02 -0800 (PST) Received: by mail-yw0-x22e.google.com with SMTP id t125so338237468ywc.1; Thu, 05 Jan 2017 02:20:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rK0hnxT2HTycomBNYV1YCM/KU/e29NdefzC+pIpUV9c=; b=WGHITqq0SJE2VewczuH0ycOqjzebs83zfPeyemlVhvNLdYOvtrGqvd6BGY0gRYi3V0 26GqoEZX7CFoK9PTwJx3rEN+nsq/y/xH8kA0FuzOsGJCiVa44c3DIX/lWQ24kStBcN5L LNiOu5WTsuszcXzOMUkDtlBug4Qi5D0gicmF0TK+A34USc9iNQ1zbr9c1IFgBkCvYZGf BqmGXQGAJpfH0kwk1Jct2+BXevT9PtLZmAAx5is2jpFTnIXEHmCTWSb3AZ4oHLnxlqpK 00Qs1Z/KpB9j3T3HM5vRHBL684OqvXbDpR9b6C95uiakIJqh6ooNsBadiyZRKy15NBAX ZzhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rK0hnxT2HTycomBNYV1YCM/KU/e29NdefzC+pIpUV9c=; b=DNyi8a2VxI/rimfK15lzGrEkxWLJ4tUyZeziOfMDDYpJVFLbTMYYlD9cM35o8UlD8s wxAuAYCxcGCb3Zfl5nvIkgpmabzdM0CLGqs7ubQBtZKWolOYEUfl54GAxCc9PyiT4Tud QdVJ0qcaXZKCGqPaBRinzZNwR8LPK5JEaR9DlCwoBXMS9ewCtIXuRNmNkju7C6pEfcEI j6YpMSLJzfBkrjWOI3VVOaD1fY/rQOLFkIEk6w5DfLpkN8iDYF2l2SXeW8doME9KE8wZ gtiR5J0m9CIQ15qerwy+h16zcnavaudzoNnH8klhIGDY/1uB+ccECXFRN0MzRakF8f// NtAQ== X-Gm-Message-State: AIkVDXKVpj8e7EwXrGFivkBwK6aT9H9mTpfp5XQvnSLglqrdpx2ETzaR7SX6e3gLN2Ab7B0q9tlVBxUsRCe+/A== X-Received: by 10.129.152.133 with SMTP id p127mr72895388ywg.281.1483611601949; Thu, 05 Jan 2017 02:20:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.172.94 with HTTP; Thu, 5 Jan 2017 02:19:41 -0800 (PST) In-Reply-To: <20170105.111102.1073811603989045784.he@uninett.no> References: <48EECE17-E5F3-452A-88A3-DF1891466AEE@employees.org> <20170105.111102.1073811603989045784.he@uninett.no> From: Naveen Kottapalli Date: Thu, 5 Jan 2017 15:49:41 +0530 Message-ID: To: Havard Eidnes Content-Type: multipart/alternative; boundary=94eb2c0bc3e284deb60545563e41 Archived-At: Cc: 6man WG , v6ops list Subject: Re: [v6ops] Why is 0 UDP checksum not valid for IPv6? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 10:20:04 -0000 --94eb2c0bc3e284deb60545563e41 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks a lot. Yours, Naveen. On 5 January 2017 at 15:41, Havard Eidnes wrote: > >> > Can anyone tell why is 0 UDP checksum isn't valid for IPv6, whereas = it > >> > is valid for IPv4? > >> > >> RFC6935 > >> RFC6936 > > > > I see those two RFCs talk mainly about the usage of UDP in tunneled > > protocols, but couldn't find why it is mandated for a normal plain IPv6 > > packet carrying a UDP payload with a DNS query or a response. > > > > In general am trying to find the reason why it is mandated in IPv6 base > > specification (RFC2460) itself. > > > > Can you please clarify on the above? > > 6936 says: > > The key difference between UDP usage with IPv4 and IPv6 is that RFC > 2460 mandates use of a calculated UDP checksum, i.e., a non-zero > value, due to the lack of an IPv6 header checksum. > > Regards, > > - H=C3=A5vard > --94eb2c0bc3e284deb60545563e41 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks a lot.

Yours,
Naveen.

On 5 January 2017 at 15:41, Havard Eidnes <he@u= ninett.no> wrote:
>> > Can anyone tell why is 0 UDP checksum isn't vali= d for IPv6, whereas it
>> > is valid for IPv4?
>>
>> RFC6935
>> RFC6936
>
> I see those two RFCs talk mainly about the usa= ge of UDP in tunneled
> protocols, but couldn't find why it is mandated for a normal plain= IPv6
> packet carrying a UDP payload with a DNS query or a response.
>
> In general am trying to find the reason why it is mandated in IPv6 bas= e
> specification (RFC2460) itself.
>
> Can you please clarify on the above?

6936 says:

=C2=A0 =C2=A0The key difference between UDP usage with IPv4 and IPv6 is tha= t RFC
=C2=A0 =C2=A02460 mandates use of a calculated UDP checksum, i.e., a non-ze= ro
=C2=A0 =C2=A0value, due to the lack of an IPv6 header checksum.

Regards,

- H=C3=A5vard

--94eb2c0bc3e284deb60545563e41-- From nobody Thu Jan 5 08:10:19 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5111712958C; Thu, 5 Jan 2017 08:10:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 pK9YJgL6DZXU; Thu, 5 Jan 2017 08:10:12 -0800 (PST) Received: from mail-pg0-x244.google.com (mail-pg0-x244.google.com [IPv6:2607:f8b0:400e:c05::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C333D129577; Thu, 5 Jan 2017 08:10:12 -0800 (PST) Received: by mail-pg0-x244.google.com with SMTP id i5so41134395pgh.2; Thu, 05 Jan 2017 08:10:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ehXc6bbh8xuClBOUUUA7gOry+qmJhr7hqpOaUxQ/KX0=; b=PBtYaD7OgL87IfQzgWzmFOZeJALU2PoFAARs2pNM2Iy/Wno9yDMyK5yiL8pRMB2M8U DkriFTXyT4y1MdwUiRACy4WMRky3VXC62Xzo8hLwVUaJeE0QIANhPFhG4F8R6Z+c03nu BLnOkNX1JVHh9z6XeHs3NJ5HvTcvYnoM+WeLQg6xgIYXNZm8zkZaIC13qQVk+MB2r2l/ O3fe0TU5BBJotEL2wu+X9lnPd3ZhJVGb1wAe6bLG5T7rvWdVNgaZSFqbrcphDFmTDKT1 5RvzuS/LUGGFe9wjMXQO/7DNXAe3AJjkxKM4saji37Yf/StNF8dgGeI8ykeQrUFjgBNr 27iA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ehXc6bbh8xuClBOUUUA7gOry+qmJhr7hqpOaUxQ/KX0=; b=UJKZ6EqQja94eUjT6MEIZGZaUlKt1xHbACju36gab5717IHKk9Hijr9L42VN6zMaks oPtBejoTwSTihR24YGgAORoCQnX4V8d4y5NvP/uaH1YemS/inufHcVa4R05YfGljksDf 1JzCfqQwNUDop3KdQiDruepqE7OCeP1LWQ6n0DgWixPc2DaYiNRIOuqbMEll8ZCSkz1i QSutJLSCRKARYW86zXjzU1XLqM/7hHL47kQjKnsN39vWzJHowsOhUia/60IXBNNPemB3 e72CfwGlxZB7hBx4v0sGyG9hHh3Nyq+thPSRUGWYQZ0cZw6sAJcahtqLBK2qWZWCFsHO mo8g== X-Gm-Message-State: AIkVDXLvw16/QxRUvCe9QRjdm9r83h5IEw2UzASDPewfNrhhK29HSKspGzPU7R4SD3TPJg== X-Received: by 10.99.218.85 with SMTP id l21mr134577182pgj.102.1483632612379; Thu, 05 Jan 2017 08:10:12 -0800 (PST) Received: from [192.168.1.2] (wsip-184-191-158-59.sd.sd.cox.net. [184.191.158.59]) by smtp.gmail.com with ESMTPSA id 186sm154659470pfv.61.2017.01.05.08.10.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Jan 2017 08:10:11 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Fred Baker In-Reply-To: Date: Thu, 5 Jan 2017 08:10:13 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <0E543D67-DF12-4736-A874-C4C52E6D91CA@gmail.com> References: <48EECE17-E5F3-452A-88A3-DF1891466AEE@employees.org> To: Naveen Kottapalli X-Mailer: Apple Mail (2.3259) Archived-At: Cc: 6man WG , v6ops list Subject: Re: [v6ops] Why is 0 UDP checksum not valid for IPv6? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 16:10:14 -0000 > On Jan 5, 2017, at 2:07 AM, Naveen Kottapalli = wrote: >=20 > I see those two RFCs talk mainly about the usage of UDP in tunneled = protocols, but couldn't find why it is mandated for a normal plain IPv6 = packet carrying a UDP payload with a DNS query or a response. The primary difference that triggered this is that whereas IPv4 has a = header checksum, IPv6 does not, and there have been anecdotal reports of = checksum errors being found in IPv4 packets in the wild. The IPv6 = designers, mid-1990's, felt that not having a checksum AT ALL left room = for concern, and leaving it to the application was too loose a rule.=20= From nobody Fri Jan 6 02:20:14 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD01129CA7 for ; Fri, 6 Jan 2017 02:20:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.091 X-Spam-Level: X-Spam-Status: No, score=-4.091 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=sonusnetworks.onmicrosoft.com 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 ilFxKrlom6a9 for ; Fri, 6 Jan 2017 02:20:11 -0800 (PST) Received: from us-smtp-delivery-211.mimecast.com (us-smtp-delivery-211.mimecast.com [63.128.21.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7805C1293FB for ; Fri, 6 Jan 2017 02:20:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=hPN1HhX7BOA3bfHfg2BWnIM8zFgOnn4JHreXAq9dn6g=; b=kAKEKVidVhFWF15RwK1W1je7HauCT5V72VpdoW7pGKH4ZP/nKZcd+pBcL1e+iwiLk6ZkeUfysOksdE6d2b3wk3wX6hsatTZe8IC48wE3chq2A7qUfYnBa5P6BnEcV9WonH5HrYZWIbFppUovRrGJkWIenWYHZgTt0A7aJSYfrck= Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03lp0049.outbound.protection.outlook.com [216.32.180.49]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-128-uHBCLPM-OhqSREdZFnCWYA-1; Fri, 06 Jan 2017 05:20:08 -0500 Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2349.namprd03.prod.outlook.com (10.166.210.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.11; Fri, 6 Jan 2017 10:20:05 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) by SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) with mapi id 15.01.0803.021; Fri, 6 Jan 2017 10:20:05 +0000 From: "Asveren, Tolga" To: Fred Baker Thread-Topic: [v6ops] RFC6555 / Multiple interfaces Thread-Index: AdJd8SFBepmXKJ7HSuuR2VCwtJY5xwB2CikAABQvbXAAANEQgAAWRS+AAQgXVC4AJijfEAABLeoAAAZl7wAAAwjNgAAUfRJgACQJ5QAAb61Q4A== Date: Fri, 6 Jan 2017 10:20:05 +0000 Message-ID: References: <6cc8fa42-cb66-816b-f000-3635cde9cc90@gmail.com> <651319E6-BF0B-4700-B875-EA77440EB2C4@gmail.com> <09a4f40a-e996-df5f-23cb-771d1ac144c5@bogus.com> <7449180F-C468-46BC-B5ED-CB9D3B97E7A6@gmail.com> In-Reply-To: <7449180F-C468-46BC-B5ED-CB9D3B97E7A6@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: 7c8bb21f-fd6a-4e93-0c31-08d4361d9578 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SN2PR03MB2349; x-microsoft-exchange-diagnostics: 1; SN2PR03MB2349; 7:VdKh38QmTM301noNhpQBxPVI3Kz8R/Iz2vD9346N3IjeHO5fNkqn+y5mkZFIHa/XrhjdrBlo2Yq3+N7FnRxezwPo8e9H0E8f6v2gdfpYaLSMYpuNYCxjLcqofY9VyLkMQi7WmgFTyEnTx5MdFyMrsddFrMaDj4OXxhzcKWXLH5FRRU5HDp1fruRXFqb6OY9oiibocXQTRqqiFp9xrjGXoR5Ax7NOZGjonT4S60lX7I720fhv0pVx/lOp5eDnDNVA8szjxl3DLVdhuyP5idT9uLXReglSF7MgZQINXMC50BZQhmj93PQugf9e4BsgrH1WExb/PW/65uuKc9AtnH7SsHW0e3Y4nioxWZXGdZadNCX0k8pM0ZqIsaFENqUcTCnGgdotROxd/uEIWOG5VaMVSD2EAbJYgdcgJjm7hjhQUFYVMk2v6H5v5KJFTW6QOl/L9b26/Xe9VVnVpA0ivMjrcw== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123560025)(20161123564025)(20161123562025)(20161123555025)(6072148)(6047074); SRVR:SN2PR03MB2349; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2349; x-forefront-prvs: 01792087B6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(24454002)(377454003)(13464003)(189002)(199003)(57704003)(39060400001)(77096006)(68736007)(38730400001)(6506006)(106356001)(2900100001)(229853002)(66066001)(554214002)(6436002)(105586002)(25786008)(76176999)(50986999)(9686002)(54356999)(92566002)(8676002)(305945005)(101416001)(5660300001)(8936002)(122556002)(102836003)(3846002)(6116002)(93886004)(97736004)(7736002)(81156014)(81166006)(74316002)(2950100002)(4326007)(189998001)(2906002)(6916009)(3660700001)(54906002)(33656002)(86362001)(55016002)(99286003)(3280700002)(110136003)(7696004); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2349; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jan 2017 10:20:05.3372 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2349 X-MC-Unique: uHBCLPM-OhqSREdZFnCWYA-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] RFC6555 / Multiple interfaces X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 10:20:13 -0000 Aren't all the technical arguments why RFC6555 was needed applicable for mu= ltiple interfaces as well? I think the same problems/outcome would be there= if, for example, IPv6 connection is tried only on one interface and that h= appens to fail while at the same time it would have succeeded on an alterna= te interface. Similarly, I think the situation is the same as far as "Isn't this obvious,= why do we need to specify it" front is concerned. Overall, one could argue that any purely local procedure without any impact= on the on-the-wire protocol does not to be standardized. But then, this ar= gument would be applicable to RFC6555 (to many other specifications) as we = ll. I think it would be better if RFC6555 briefly mentioned about use of multip= le interfaces:, e.g. "Entities following procedures in RFC6555 SHOULD perfo= rm connection checks for each interface in parallel, if an IP Address Famil= y can utilize more than one interface. While doing so, they MAY consider ot= her factor and parameters, e.g. a priori knowledge about user preferences f= or particular applications, interface capabilities." What I am looking for is just a home for such a clarification -as it is cur= rently not present in RFC6555-. Thanks, Tolga > -----Original Message----- > From: Fred Baker [mailto:fredbaker.ietf@gmail.com] > Sent: Tuesday, January 03, 2017 10:38 PM > To: Asveren, Tolga > Cc: joel jaeggli ; v6ops@ietf.org > Subject: Re: [v6ops] RFC6555 / Multiple interfaces >=20 > I worry about the implementation of the musts and shoulds. How does a > random application, that doesn't necessarily know much about the OS or > hardware underneath it, know whether two addresses are on the same or > different interfaces? Yes, there are platforms in which they do. That's n= ot "all > platforms", not by a long shot. >=20 > Personally, I would focus on ensuring that the problem is describable, > repeatable, and real before working on, or embellishing, a solution. With= HE, > there was a real problem - dual stack systems sometimes (demonstrably) > waited for amazingly long times (anecdotal evidence says there were cases > up to half an hour) before a TCP time-out occurred, making such platforms > difficult for a real user to depend on without turning IPv6 off. HE is fa= r from a > perfect solution, but it turns out to be enough of a solution that the or= iginal > problem isn't very real now. >=20 > Tell me about the problem you're trying to solve. What are the symptoms? = Is > it reproducible? Who is feeling pain? How do we know when we have solved > it? >=20 > > On Jan 3, 2017, at 3:58 AM, Asveren, Tolga > wrote: > > > > Maybe a two-step approach? > > > > i- "Entities following procedures in RFC6555 SHOULD perform connection > checks for each interface in parallel, if an IP Address Family can utiliz= e more > than one interface. While doing so, they MAY consider other factor and > parameters, e.g. a priori knowledge about user preferences for particular > applications, interface capabilities." > > > > IMHO this should be stated in a "Standards Track" specification. > > > > ii- Other specifications, probably all/mostly "Informational", providin= g > recommendations about Socket API usage, interface type specific > procedures etc... > > > > Would such a split make sense? I know i- could be considered as "too > little/no brainer" but that arguably may be true for RFC6555 in general - > especailly the "obviousness"-. > > > > Thanks, > > Tolga > > > >> -----Original Message----- > >> From: Fred Baker [mailto:fredbaker.ietf@gmail.com] > >> Sent: Monday, January 02, 2017 7:39 PM > >> To: joel jaeggli > >> Cc: Asveren, Tolga ; v6ops@ietf.org > >> Subject: Re: [v6ops] RFC6555 / Multiple interfaces > >> > >> > >>> On Jan 2, 2017, at 3:12 PM, joel jaeggli wrote: > >>> > >>> I wonder whether this can be formulated as a nice tight algorithm or > >>> if this is just a set of heuristics that need to be incompletely > >>> applied depending on your use case. > >> > >> Probably that. > > From nobody Sat Jan 7 12:50:38 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 723C6129B72 for ; Sat, 7 Jan 2017 12:50:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=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 P4RtpcmFir_W for ; Sat, 7 Jan 2017 12:50:33 -0800 (PST) Received: from atl4mhob14.myregisteredsite.com (atl4mhob14.myregisteredsite.com [209.17.115.52]) by ietfa.amsl.com (Postfix) with ESMTP id 04CD3129B6F for ; Sat, 7 Jan 2017 12:50:32 -0800 (PST) Received: from mailpod.hostingplatform.com ([10.30.71.205]) by atl4mhob14.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id v07KoSAk011111 for ; Sat, 7 Jan 2017 15:50:28 -0500 Received: (qmail 7184 invoked by uid 0); 7 Jan 2017 20:50:28 -0000 X-TCPREMOTEIP: 68.100.192.186 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?192.168.0.12?) (lee@asgard.org@68.100.192.186) by 0 with ESMTPA; 7 Jan 2017 20:50:27 -0000 User-Agent: Microsoft-MacOutlook/14.7.1.161129 Date: Sat, 07 Jan 2017 15:50:27 -0500 From: Lee Howard To: v6ops list , Message-ID: Thread-Topic: [v6ops] Comments on draft-ali-ipv6rtr-reqs-01 References: In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3566649029_45201278" Archived-At: Subject: Re: [v6ops] Comments on draft-ali-ipv6rtr-reqs-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2017 20:50:36 -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_3566649029_45201278 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable This is a hat-off document review. General notes: I love this document. One of the best operations-related documents I=B9ve see= n at the IETF. The Architecture Review I think should be a separate document. It=B9s excellent, but I can imagine many other documents wanting to refer just to that portion. It may be appropriate in rtgwg, too. If you=B9re going to say =B3routers,=B2 use that word throughout; to me, a =B3network device=B2 is a device on a network, not necessarily one that forward= s at layer 3. Specific notes: Are there really six authors? Sure some of them contributed text, while jus= t a few are document authors. Don=B9t forget the Abstract. Section 1. Are there references for the definitions of =B3routers=B2 and =B3middleboxes=B2 you could reference (e.g., rfc7663 =B3Report from the IAB Workshop on Stack Evolution in a Middlebox Internet (SEMI)=B2)? Paragraph =B3Readers should recognize=B2 is great. Replace =B3This memo will only interact=B2 with =B3This memo will only discuss=B2. Is there an IPv4 router requirements doc, foc citation/comparison? 2.1 The first paragraph is excellent. Additional note, though: different implemtnations may increase robustness in the face of a weakness or vulnerability that only affects one. First bulleted paragraph: Should it be =B3applications=B2 instead of =B3software=B2 in the first bulleted paragraph? For instead, I=B9d rather say, =B3Applications should deal with erro= r states gracefully=B2 than =B3Software should be written to deal with error states gracefully.=B2 And, =B3it should do so in a way that does not spread false reachability information, or allow false information to remain.=B2 Then= , as a separate sentence, =B3It should also not fail in a way overloads=8A=B2 Second bulleted paragraph is a great point. Third bullet should reference rfc5218 =B3What Makes for a Successful Protocol?=B2 Fourth bullet should, too, plus reference draft-iab-protocol-transitions. The last bullet needs more detail. Should you ignore bits that are not in wide use, or handle them a specific way? IN any case, have to handle errors gracefully (as you said above). 2.2 s/impese/impede ? =B3as simple as possible=B2 is often appended, =B3and no simpler.=B2 That gets at your point: if it=B9s too simple, it may not solve your problem. However, a counterpoint: Some problems turn out not to be worth solving due to the complexity introduced. See IRTF=B9s ncrg. I=B9d add a sentence or clause to the =B3Elegance is the goal=B2 paragraph to include clarifying the problem (some solutions solve what you think the problem is, but often the problem is =B3net expense is too high=B2 or =B3latency is too high for X applications=B2 rather than =B3our MEDs need tuning=B2). Totally agree about tradeoffs. I want to add that competing optimizations can=B9t optimize for everything, but sometimes it=B9s obvious what to optimize for. For instance, adding a bit of state on a device that is loaded with unused resources is fine. Again, in =B3The amount of state=B2 I=B9d refer to ncrg; I think it=B9shttps://tools.ietf.org/html/draft-irtf-ncrg-complexity-framework-01 Also, this paper using state as a metric for complexity:https://people.eecs.berkeley.edu/~sylvia/papers/netcomp.pdf [citation needed] for =B3All nontrivial abstractions leak.=B2 The bullet =B3The desired optimization=B2 isn=B9t clear to me. Do you mean efficiency? Something else? I=B9d like to see the triangle problem reworked into easily stated points. state/interactions/optimization isn=B9t quite there, but the idea of what I mean. 2.3 Hourglass [citation needed?] You include MPLS, which is confusing later. MPLS router or MPLS switch? You see the problem with including it in the document, without explicit and constant sidebars about L2/L3? In the paragraph =B3These protocols=B2 you should refer back to your statement that all abstractions leak (2.2) 2.4 3rd bullet is hand-waving. What information must be handled locally? Does local mean =B3on this router=B2 or =B3on this card=B2 or =B3in this AS=B2? HBH headers? =B3etc.=B2 is really vague. Also, the paragraph =B3When consulting=B2 is explicitly about IP routers: MPLS doesn=B9t do a longest prefix match. 3.1=20 citations needed for SNMP and MIB definitions. =B3Network devices should place a priority on supporting machine readable APIs.=B2 Do you mean device maufacturers should focus on writing code to do that, or do you mean the devices should prioritize API config bits somehow? I think you mean =B3Router manufacturers should focus on developing machine-readable APIs.=B2 But I=B9m not sure I agree, since to prioritize something means to implicitly deprioritize something else (if everything=B9s = a priority, nothing is), and I don=B9t want to encourage vendors to prioritize APIs over CLI. 3.2 SHould mention AAA. 3.3 =B3To reach this goal, IPv6 network devices should=8A=B2 SHOULD? You mean routers, not devices connected to a network? btw, we=B9re more than half way through the document, and this is the first mention of anything specific to IPv6. That=B9s why I think the first half should be a separate doc. This section should make reference to ANIMA and SUPA WG efforts, even if just for awareness. Maybe HNCP (Homenet), too. All of those efforts could make a difference in this area. 3.4 =B3The network control plane=B2 needs a verb. "DoS and DDoS attacks directly on network devices=B2 should be =B3DoS and DDoS attacks directly against routers.=B2 Typo: authentication =B3These techniques=B2 should start a new sentence. 4. Second bullet: not just lots of information, but lots of queries (overhead in packet size and processing) =B3There are three broad=B2 is a great breakdown of what you=B9re describing. 4.1 after =B3human readability=B2 I=B9d highlight that software can translate for humans. Again in the NETCONF/RESTCONF paragraph, =B3current focus=B2 could mean =B3prioritize this and let other relevant efforts slide.=B2 But I basically agree with the point you=B9re making about a single modeling language. 4.2 First paragraph could use more detail. Why is this important? s/Traffic Engineer/Traffic Engineering Yes, please add the missing sections, but make sure titles agree with your outline (e.g., top of p. 12 says =B3device state, topology state, and flow state,=B2 but the headings don=B9t match, especially at =B34.3 Traffic Flow and Traceability.=B2 5. SHOULD? 5.1 Yes, address !=3D host identifier, but why? 5.2 2nd bullet, is there a reference to cite for this? The bullet =B3Configuring an prefix length longer than a /64=8Ashould require additional configuration steps=8A=B2 Hmm. I=B9m not sure about this one. More discussion required. The following paragraph is good. 5.3 =B3(History of MTU is not a happy one)=B2 made me smile The bullet on ineffectiveness of pMTUd should refer to something. . . mayb= e the recommendations on ICMP filtering? Where=B9d the numbers come from for delaying serialized packets? It=B9s useful; is it just math, or is there a reference? I hadn=B9t thought about this before. 5.4. You don=B9t mention ping. ICMP is blocked to prevent reconn attacks. 5.6 I wish you luck! In all of these sections, should there be a statement that none of {IPv4, IPv6, MPLS} can require any of the others? i.e., =B3IPv6 MUST NOT require IPv4 in order to work.=B2 (rfc6540) The Security Considerations section is weak. There=B9s a lot to consider, and a document detailing router requirements really ought to discuss security pretty thoroughly. Keep at it: this could be great. Lee --B_3566649029_45201278 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
This is a hat-off document rev= iew.

General notes:
I love th= is document. One of the best operations-related documents I’ve seen at= the IETF.
The Architecture Review I think should be a separat= e document. It’s excellent, but I can imagine many other documents wan= ting to refer just to that portion. It may be appropriate in rtgwg, too.

If you’re going to say “routers,&#= 8221; use that word throughout; to me, a “network device” is a d= evice on a network, not necessarily one that forwards at layer 3.

Specific notes:
Are there really six au= thors? Sure some of them contributed text, while just a few are document aut= hors.

Don’t forget the Abstract.

Section 1.
Are there references for= the definitions of “routers” and “middleboxes” you = could reference (e.g., rfc7663 “Repor= t from the IAB Workshop on Stack Evolution in a Middlebox Internet (SEMI)= 221;)?

Paragraph= “Readers should recognize” is great. Replace “This memo w= ill only interact” with “This memo will only discuss”.

Is there an IPv4 router requirements doc, foc citation= /comparison?

2.1 The first paragraph is excellent. = Additional note, though: different implemtnations may increase robustness in= the face of a weakness or vulnerability that only affects one.
First bulleted paragraph:
Should it be “applica= tions” instead of “software” in the first bulleted paragra= ph? For instead, I’d rather say, “Applications should deal with = error states gracefully” than “Software should be written to dea= l with error states gracefully.” And, “it should do so in a way = that does not spread false reachability information, or allow false informat= ion to remain.” Then, as a separate sentence, “It should also no= t fail in a way overloads…”

Second bull= eted paragraph is a great point.

Third bullet shoul= d reference rfc5218 “What Makes for a Successful Protocol?”

Fourth bullet should, too, plus reference draft-iab-pro= tocol-transitions.

The last bullet needs more detai= l. Should you ignore bits that are not in wide use, or handle them a specifi= c way? IN any case, have to handle errors gracefully (as you said above).

2.2
s/impese/impede ?

<= div>“as simple as possible” is often appended, “and no sim= pler.” That gets at your point: if it’s too simple, it may not s= olve your problem.
However, a counterpoint: Some problems turn out= not to be worth solving due to the complexity introduced. See IRTF’s = ncrg.

I’d add a sentence or clause to the = 220;Elegance is the goal” paragraph to include clarifying the problem = (some solutions solve what you think the problem is, but often the problem i= s “net expense is too high” or “latency is too high for X = applications” rather than “our MEDs need tuning”).

Totally agree about tradeoffs. I want to add that competin= g optimizations can’t optimize for everything, but sometimes it’= s obvious what to optimize for. For instance, adding a bit of state on a dev= ice that is loaded with unused resources is fine.

A= gain, in “The amount of state” I’d refer to ncrg; I think = it’shttps://tools.ietf.org/html/draft-irtf-ncrg-complexity-framework= -01
Also, this paper using state as a metric for complexity:https://= people.eecs.berkeley.edu/~sylvia/papers/netcomp.pdf

=
[citation needed] for “All nontrivial abstractions leak.”

The bullet “The desired optimization” is= n’t clear to me. Do you mean efficiency? Something else?
I’d like to see the triangle problem reworked into easily = stated points. state/interactions/optimization isn’t quite there, but = the idea of what I mean.

2.3
Hourglass [c= itation needed?]
You include MPLS, which is confusing later. MPLS = router or MPLS switch? You see the problem with including it in the document= , without explicit and constant sidebars about L2/L3?

In the paragraph “These protocols” you should refer back to y= our statement that all abstractions leak (2.2)

2.4 = 3rd bullet is hand-waving. What information must be handled locally? Does lo= cal mean “on this router” or “on this card” or ̶= 0;in this AS”? HBH headers? “etc.” is really vague.
<= div>
Also, the paragraph “When consulting” is expl= icitly about IP routers: MPLS doesn’t do a longest prefix match.
=

3.1 
citations needed for SNMP and MIB de= finitions.

“Network devices should place a pr= iority on supporting machine readable APIs.” Do you mean device maufac= turers should focus on writing code to do that, or do you mean the devices s= hould prioritize API config bits somehow? I think you mean “Router man= ufacturers should focus on developing machine-readable APIs.” But I= 217;m not sure I agree, since to prioritize something means to implicitly de= prioritize something else (if everything’s a priority, nothing is), an= d I don’t want to encourage vendors to prioritize APIs over CLI.
=

3.2 SHould mention AAA.

3.3
“To reach this goal, IPv6 network devices should…”<= /div>
SHOULD?  You mean routers, not devices connected to a network= ?

btw, we’re more than half way through the d= ocument, and this is the first mention of anything specific to IPv6. That= 217;s why I think the first half should be a separate doc.

This section should make reference to ANIMA and SUPA WG efforts, eve= n if just for awareness. Maybe HNCP (Homenet), too. All of those efforts cou= ld make a difference in this area.

3.4 “The n= etwork control plane” needs a verb.

"DoS and = DDoS attacks directly on network devices” should be “DoS and DDo= S attacks directly against routers.”

Typo: au= thentication
“These techniques” should start a new sen= tence.

4.
Second bullet: not just lots of= information, but lots of queries (overhead in packet size and processing)

“There are three broad” is a great break= down of what you’re describing.

4.1 after = 220;human readability” I’d highlight that software can translate= for humans.

Again in the NETCONF/RESTCONF paragrap= h, “current focus” could mean “prioritize this and let oth= er relevant efforts slide.” But I basically agree with the point you&#= 8217;re making about a single modeling language.

4.= 2 First paragraph could use more detail. Wh= y is this important?

s/Traffic Engineer= /Traffic Engineering

Yes, please add the missing se= ctions, but make sure titles agree with your outline (e.g., top of p. 12 say= s “device state, topology state, and flow state,” but the headin= gs don’t match, especially at “4.3 Traffic Flow and Traceability= .”

5. SHOULD?

5.1 Ye= s, address !=3D host identifier, but why?

5.2 2nd bul= let, is there a reference to cite for this?

The bul= let “Configuring an prefix length longer than a /64…should requi= re additional configuration steps…”  Hmm. I’m not sur= e about this one. More discussion required.
The following paragrap= h is good.

5.3
“(History of MTU is = not a happy one)” made me smile

The bullet on= ineffectiveness of pMTUd should refer to something. . .  maybe the rec= ommendations on ICMP filtering?

Where’d the n= umbers come from for delaying serialized packets? It’s useful; is it j= ust math, or is there a reference? I hadn’t thought about this before.=

5.4. You don’t mention ping.
ICMP = is blocked to prevent reconn attacks.

5.6 I wish yo= u luck!

In all of these sections, should there be a= statement that none of {IPv4, IPv6, MPLS} can require any of the others? &n= bsp;i.e., “IPv6 MUST NOT require IPv4 in order to work.” (rfc654= 0)

The Security Considerations section is weak. The= re’s a lot to consider, and a document detailing router requirements r= eally ought to discuss security pretty thoroughly.

=
Keep at it: this could be great.

Lee=


--B_3566649029_45201278-- From nobody Sun Jan 8 21:56:59 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E330E129ADF for ; Sun, 8 Jan 2017 21:56:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 YNWs4yybqBFg for ; Sun, 8 Jan 2017 21:56:57 -0800 (PST) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2D5B129ADB for ; Sun, 8 Jan 2017 21:56:56 -0800 (PST) Received: by mail-pf0-x22c.google.com with SMTP id 127so28226743pfg.1 for ; Sun, 08 Jan 2017 21:56:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=OY8+XiCSTdbBvkO791cqyFbKYBx1GQHsxCy9OpzkexU=; b=C5139/4DsjpNw6nKCX6jIG1Fu7BW9/HnLs6wA5lXNeSIjeqxfgP5mBx5rozDAROsTG 6SKMrU1jHVu/dhonetDsQDISvItzB//IVum4ILi2foc8hQ6XNA+zFcONbZmbI7jNlxN6 Y1Rg8y1t0QKujEC13Gdkv40I3tmdPQ+KArmoDXtWrOxpKP/6iUb5miZDbe2xV5RGaVYn NllsyNYmpPKU9wjAKyREZamhE7bokkV7inC/KhI9cEQNtu/pda5lKUhxbJ8zhqxj9Tc6 Ka3BBe2xKA/6y+ag8+gaW0wfjOyFms+S1/b/OfQlvfB5jBC46FWKxIHcuMjwDQhx80cq W6AA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=OY8+XiCSTdbBvkO791cqyFbKYBx1GQHsxCy9OpzkexU=; b=rO2DbNZbixcPDCpQ4ovQDKSFAtTG3VX8SEr39MKCsTb6umby5P2/F6vaJixLSQ/3i1 nkH1QFLCHKdewPQtMLH3XjpZo/J/wOQciurnsokcQGnk69Uaek/mVeAONuO21k5So5OE ChP4ToTC6Mof63B71ffx+sspGy3rmUlaOJlxuH5eY2tQY7OosUuTSbNQYjvOmYOdnyMM Dcw6B/j+PGedpzxIb3x0tHOkAs4fNJrkCeA6e6e2EPZzAUB8esALOYnc3jFOe/ur7dd7 o0jSOO79q3Vem30NaRL3Rg6LN8pmPJ+aPaOVf8YLQ8GM3NMTD84AgtFcF4Mf4ZK9igfi xoRQ== X-Gm-Message-State: AIkVDXIGTsPeBsdTAI4ZUKnxSxiXkf8SujKCk/57VN4UJJ3jXtG68bMByycnMdDCN75pbQ== X-Received: by 10.99.127.71 with SMTP id p7mr8938185pgn.125.1483941416499; Sun, 08 Jan 2017 21:56:56 -0800 (PST) Received: from [192.168.1.20] (wsip-184-191-158-59.sd.sd.cox.net. [184.191.158.59]) by smtp.gmail.com with ESMTPSA id p5sm163181429pgk.23.2017.01.08.21.56.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 08 Jan 2017 21:56:55 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Fred Baker In-Reply-To: Date: Sun, 8 Jan 2017 21:56:59 -0800 Content-Transfer-Encoding: 7bit Message-Id: References: To: Lee Howard X-Mailer: Apple Mail (2.3259) Archived-At: Cc: v6ops list , draft-ali-ipv6rtr-reqs@tools.ietf.org Subject: Re: [v6ops] Comments on draft-ali-ipv6rtr-reqs-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 05:56:59 -0000 > On Jan 7, 2017, at 12:50 PM, Lee Howard wrote: > > Is there an IPv4 router requirements doc, foc citation/comparison? It's dated, but one could mention RFC 1812. From nobody Tue Jan 10 10:18:37 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E594B129D7C for ; Tue, 10 Jan 2017 10:18:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 O5uxAcubJ02k for ; Tue, 10 Jan 2017 10:18:28 -0800 (PST) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDCFC129D53 for ; Tue, 10 Jan 2017 10:18:25 -0800 (PST) Received: by mail-pf0-x22e.google.com with SMTP id y143so29963201pfb.0; Tue, 10 Jan 2017 10:18:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mQFW0s4KpgiuspyT2gfUAg98VlrCW6Q+pZkpAJ7CvhQ=; b=IXSJE482JM+Jb2zOP91y5X2WAet0GLWDTh094RUK3wEyQHdkZVmz4JoLhNCVK1l/1b k+Rmh6qlCfKsXicNShLE7kd7zQdycYT2zyDgAWtqJAtF3B0e21bDinKfr8BN7ukXINsc t9KQ4HiJ5L/8JRDRdcmpvXvk8wjkKTGP/F6qIJycXMfxX1D6C2NYrrVykcw4sbVyxH/c 0LDkremKpxR18+Qup99+vK6iyzH0lIU6zVSXG6N9cJWvjvN+qYXwgQ6DVOf2/PWmeUWg KAxRjPIUFVjBTLCnFQlthxA2D/lmc3+c3ljPS5WUiD7+H5QMyvsojlyxy7eea6po7JrC dnUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mQFW0s4KpgiuspyT2gfUAg98VlrCW6Q+pZkpAJ7CvhQ=; b=nlzrkj4enaWicnVURPsRMuu5fU6oM6AFYcRB0rXAQvSQjwZqX6cxOhaw/FViPSnvGt vZx0a86fV6Qa2kEZyGN7TQD6NnRIpOcAlZMIFGfwARLH6Migai/bRdRtXr3unltlkMAo UUibLMPOrcoki1J2hbMHF17n3sq5MyETooBU0DeF/KwV1JeqDOWgspo+Z1loNG1VDAEV t0YpRKr65wGjvISGWaQSGHpMCtPr2Yk4bD+9xTFGZjMW2hAbsFqOeHACJveXagWqhDYv 3tUETyDN1GgWdGDqHvtEt4b6w1SyRDk4cEZMTurM9EGg4VR6mPmh+jf0HhtDsaBfmA7N u/Qg== X-Gm-Message-State: AIkVDXJuADhhVLPv/TDrAvjN5AL+ztlTRwl27yPkRNT9K4mBElbUBFU9MZnevZmCATzclw== X-Received: by 10.99.102.69 with SMTP id a66mr5513514pgc.49.1484072305590; Tue, 10 Jan 2017 10:18:25 -0800 (PST) Received: from [192.168.1.20] (wsip-184-191-158-59.sd.sd.cox.net. [184.191.158.59]) by smtp.gmail.com with ESMTPSA id m67sm7405774pfc.64.2017.01.10.10.18.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Jan 2017 10:18:24 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Fred Baker In-Reply-To: Date: Tue, 10 Jan 2017 10:18:26 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <35A0F76E-2D53-4304-B355-C09FA3B38D96@gmail.com> References: To: v6ops list X-Mailer: Apple Mail (2.3259) Archived-At: Cc: james woodyatt , 6man WG Chairs , INT Area Chairs Subject: Re: [v6ops] Route Information Options in Redirect Messages X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 18:18:30 -0000 Passing along a request for comments - not an RFC, an actual request. = The draft is in intarea, so commenting directly to intarea would be = appropriate. Alternatively, if v6ops wants to discuss here and then pass = along a comment, the chairs can do that. The question to us is not clearly stated, but includes at least = projected utility of the change ("this would be useful" and that sort of = thing) and any thoughts on its operational impact. > On Jan 9, 2017, at 11:02 AM, james woodyatt wrote: >=20 > On Jan 9, 2017, at 07:51, Templin, Fred L = wrote: >>=20 >> See below for a new draft that proposes to update RFC4861 and RFC4191 = to >> permit the inclusion of Route Information Options in Redirect = Messages. >> This represents a backward-compatible extension to the IPv6 ND = Redirect >> function. Please review and comment on the list. >>=20 >> >=20 > p1. I=E2=80=99m interested to see what V6OPS will think of this. >=20 > p2. Section 3.3, Host Specification says this: >=20 >>> In light of these considerations, a "Type C" host that receives a >>> Redirect message containing RIOs adopts the combined behaviors of >>> both of these specifications. Namely, the host updates its = neighbor >>> cache entry for the Target and updates its routing table per the >>> included RIOs. If the Destination address is not the unspecified >>> address, the host further updates its destination cache. >>>=20 >>> Note that "Type A'" and "Type B" hosts ignore any RIOs and process >>> the Redirect message according to Section 8.3 of [RFC4861]. >=20 > And I wonder if you have considered the possibility of a =E2=80=9CType = D=E2=80=9D host, which in my conception would be capable of *only* = processing RIO options that appear in ND Redirect messages and *not* in = RA messages. I=E2=80=99m not sure that=E2=80=99s a type of host we want = to encourage, but the idea of its possibility was one of the first = things that sprang to mind when I contemplated the reasons why so few = Type C hosts are currently deployed in the wild after more than a decade = since RFC 4191 was published. >=20 >=20 > --james woodyatt >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Wed Jan 11 07:37:14 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16C0D1294DF for ; Wed, 11 Jan 2017 07:37:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com 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 QadH6klMzD2B for ; Wed, 11 Jan 2017 07:37:11 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0117.outbound.protection.outlook.com [104.47.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A6D61294C5 for ; Wed, 11 Jan 2017 07:37:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6U+EsLUR9AMAi08/1fRUihpv+x0z+/dzGuCIAoNmI7k=; b=RQvgaKxJhAkYQwnXgBTRgfggDy3ozd461af2NmeKYHmWt+pON9sRoBYjxsQ6o9PMLgzklbdZrkNX60NSBvsgITiSLa5w6DZHJV2f6uJLm2TG8hGKdUvAaQBf+2NbtbjVHRcYKhNZLvBbVjJgwZGiqJn20KvicIn+Pq9jc5oO9VE= Received: from SN1PR0501MB2062.namprd05.prod.outlook.com (10.163.227.23) by SN1PR0501MB2062.namprd05.prod.outlook.com (10.163.227.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.845.6; Wed, 11 Jan 2017 15:37:09 +0000 Received: from SN1PR0501MB2062.namprd05.prod.outlook.com ([10.163.227.23]) by SN1PR0501MB2062.namprd05.prod.outlook.com ([10.163.227.23]) with mapi id 15.01.0845.013; Wed, 11 Jan 2017 15:37:09 +0000 From: Ron Bonica To: IPv6 Ops WG Thread-Topic: draft-ietf-v6ops-dhcpv6-slaac-problem Thread-Index: AdJsHl8eSkgq9pmdSH+a6rrO1byUfg== Date: Wed, 11 Jan 2017 15:37:08 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rbonica@juniper.net; x-originating-ip: [66.129.241.13] x-ms-office365-filtering-correlation-id: 290229c1-c993-45d9-5846-08d43a37b46c x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:SN1PR0501MB2062; x-microsoft-exchange-diagnostics: 1; SN1PR0501MB2062; 7:mwIQMDMcQW9Me/eFa1s7PvBsffWr3B541H/ASI+HbBVWG4yulu+M8e808qrtm1k54KgeMSqcqbF5XNNpRG36wfjs9j9H+VHdpLkiVKZt9bWBu3CDOzerHTzS7bFMLQv7TF3sLuaGuTgqxDLCIHghVc2xz2yOamXZ9O1k/N1OcKWa0fdBldToWaLSaCceBHQJNDw0Pd8sfqqa6BVQnlT4HoPs2ab+P2ALLR139wCy3/XiYcrOT5Bim+YSCdoitvpf8Hbxepqgm8d4PplUQCdTNTKShlbdoh8YnvdEfURTJczRgyM3zTV4x5z0g5abkykQyq+/wLQvhrB7DsbhbKQoGfAJsM1d2ae+NHDbvDJeYpGvmWfdhXMhqLs7oInfpVCVWJV/hqfgrZpYtCVAYbJx6UgrFMKNDzG/LMIyYmW+8eTHLSfaxYHOU9AN802COB0SXTxxMk/i9TlAOEL0OwwIeg== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(20161123558021)(20161123555025)(20161123562025)(20161123564025)(6072148); SRVR:SN1PR0501MB2062; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0501MB2062; x-forefront-prvs: 01842C458A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39840400002)(39410400002)(39860400002)(39850400002)(39450400003)(199003)(189002)(38730400001)(6436002)(8936002)(77096006)(6506006)(450100001)(68736007)(9686003)(305945005)(7736002)(74316002)(81156014)(81166006)(8676002)(33656002)(92566002)(50986999)(122556002)(66066001)(105586002)(54356999)(25786008)(2906002)(110136003)(99286003)(101416001)(2900100001)(189998001)(55016002)(230783001)(106356001)(107886002)(97736004)(86362001)(7696004)(5660300001)(6916009)(3846002)(3660700001)(6116002)(102836003)(3280700002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0501MB2062; H:SN1PR0501MB2062.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jan 2017 15:37:08.8852 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0501MB2062 Archived-At: Subject: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 15:37:13 -0000 Folks, Draft-ietf-v6ops-dhcpv6-slaac-problem was introduced 3.5 years ago, but has= made little progress in the last year. Therefore, it become necessary for = the chairs to reevaluate whether this draft should continue to be a WG item= . If you have an opinion on this subject, please post it to the mailing list = by 1/25/17. Options are: 1) Continue to work on the draft with an eye toward publication in 2017 2) Allow the draft to expire Silence or limited response will be interpreted as a lack of interest in th= e draft. Ron, Lee and Fred From nobody Wed Jan 11 07:39:33 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 119FC1294DF for ; Wed, 11 Jan 2017 07:39:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.058 X-Spam-Level: X-Spam-Status: No, score=-3.058 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com 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 trXXBcQr2mrC for ; Wed, 11 Jan 2017 07:39:29 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0114.outbound.protection.outlook.com [104.47.38.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6985D128BA2 for ; Wed, 11 Jan 2017 07:39:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=tAWw0Nacm4ZljJy5+n2jpTaajTj8bqYGoh9IT0EBigA=; b=GtGiQHV6aGjm5evfSZNmk32Wdy0fDmVD3hu/4XuY6br/5lJhtfJPr2yS4DCyHvPu0xvTJNGtrDNL3Isji0fg03Qm819HB/Sm2cXfmPrAkvFyWYCIdK06gGP2fBqDokapTOM0JdzH2F7QEI3ZTpzviRHjsGSnOXDnoP9aXic0CaQ= Received: from SN1PR0501MB2062.namprd05.prod.outlook.com (10.163.227.23) by SN1PR0501MB2062.namprd05.prod.outlook.com (10.163.227.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.845.6; Wed, 11 Jan 2017 15:39:27 +0000 Received: from SN1PR0501MB2062.namprd05.prod.outlook.com ([10.163.227.23]) by SN1PR0501MB2062.namprd05.prod.outlook.com ([10.163.227.23]) with mapi id 15.01.0845.013; Wed, 11 Jan 2017 15:39:27 +0000 From: Ron Bonica To: IPv6 Ops WG Thread-Topic: draft-ietf-v6ops-ula-usage-considerations Thread-Index: AdJsIL/eGNHYeD7QSh6qBQxZ+ciwNw== Date: Wed, 11 Jan 2017 15:39:27 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rbonica@juniper.net; x-originating-ip: [66.129.241.13] x-ms-office365-filtering-correlation-id: 86f21215-8cb9-4026-9b0a-08d43a380737 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:SN1PR0501MB2062; x-microsoft-exchange-diagnostics: 1; SN1PR0501MB2062; 7:ZvwiMw0Oh+VDhKyHmbkASOREv1zfCGXN9Io7VHUlJjqc/ngCUhYV/v6iMzzZq1O7K/g/56hDINnHrtKvjX7YczWGFJ0xpCYV2q2nGgfbdfJgYs8ESwCjWu8a4Thv6Go78MuNQXQ18w/4wLmkUMtuyJnFmc7qYyjP7m/DkXjVgmN/mM3Yl2QjVOGKYUZ8e5GPX5g23NM+F5ELMlimaMDEU/D6mK8ZDE3joslZWEjnC1KHYgJy9ouEEw2RQq/OtLK4vbm/m6Ld2y3OCmDprEEwONKRsGUHxNnNPjqF+Im5k4BVpdHqXicJYsdGgbnNuIAppHBqn0WICmt7XYWAZuvAUOIThGciEHt95A1SNbGOnQjXgw4edLDJUuyN8skcnxOiMOvyl5iatwqhqQTRzjyLd3N1jEbArpqehV466UUml1aiZWLs+BXyJSBfmporZcPSS1Q9gy1DWdJW1/o4t59ygQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(20161123558021)(20161123555025)(20161123562025)(20161123564025)(6072148); SRVR:SN1PR0501MB2062; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0501MB2062; x-forefront-prvs: 01842C458A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39840400002)(39410400002)(39860400002)(39850400002)(39450400003)(199003)(189002)(38730400001)(6436002)(8936002)(77096006)(6506006)(450100001)(68736007)(9686003)(305945005)(7736002)(74316002)(81156014)(81166006)(8676002)(33656002)(92566002)(50986999)(122556002)(66066001)(105586002)(54356999)(25786008)(2906002)(110136003)(99286003)(101416001)(2900100001)(189998001)(55016002)(230783001)(106356001)(107886002)(97736004)(86362001)(7696004)(5660300001)(6916009)(3846002)(3660700001)(6116002)(102836003)(3280700002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0501MB2062; H:SN1PR0501MB2062.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jan 2017 15:39:27.9336 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0501MB2062 Archived-At: Subject: [v6ops] draft-ietf-v6ops-ula-usage-considerations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 15:39:31 -0000 Folks, D raft-ietf-v6ops-ula-usage-considerations was introduced 3.5 years ago, bu= t has made little progress in the last year. Therefore, it become necessary= for the chairs to reevaluate whether this draft should continue to be a WG= item. If you have an opinion on this subject, please post it to the mailing list = by 1/25/17. Options are: 1) Continue to work on the draft with an eye toward publication in 2017 2) Allow the draft to expire Silence or limited response will be interpreted as a lack of interest in th= e draft. Ron, Lee and Fred From nobody Wed Jan 11 08:51:37 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52B8E12952B for ; Wed, 11 Jan 2017 08:51:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 mJVdu2UlwGum for ; Wed, 11 Jan 2017 08:51:34 -0800 (PST) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD8F6129434 for ; Wed, 11 Jan 2017 08:51:34 -0800 (PST) Received: by mail-oi0-x229.google.com with SMTP id w204so95654963oiw.0 for ; Wed, 11 Jan 2017 08:51:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=CDbjlssZmzf72iytpWRZkSGGGj13vUF+gZPya9u2NJc=; b=cpgu1lyMShvWiX2tHdF3pOXbdi8GD4GuTk1BVlW2Jb+/E00tbOGasxg58KpCLqm/Hv ZcQdTrOYEJnTxgCs4LFJmufRwK4ksIW9hUK0TM8+7//HvgZN7tcTYhMOpbXQvZ86Nd8V faL0WhVQ2IplTDRaxYWQAITsReqxaF9OKaWM3+H0N2yJrUaR1OoA66WfuRXzD/OXcjfG Vpbo34hGCCCZWIna7am5PRLoHLJY2m/0VCmJihHQ3ds9dYxGUxl6k14l+wGLg5CC2qmk Ydw5dXgcxXYIKKhbi3DBNSESLVurLtCDl5x5uHYc9+W8m+AP3/bRbkJhy3XoXOJhTlt0 0CBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=CDbjlssZmzf72iytpWRZkSGGGj13vUF+gZPya9u2NJc=; b=JfQLpvd2AZMCGRZNZ8y2/3gt16pM4yMc2BnHJxPJBbWVl3T4UTmWsVSkBeh/4Lj1ND mVhHnJ6zpcEb9wgWJCQ8m0HBjPrPfnIUJEO9rU4g0lN0TYh5gKXxZ4e1Dqhw3DQDtJOS 4L/NWqphvKi+OI/xeSIUXyqF9n9NSwzwkUSOv7zsv8lFr90fWckittbkCLmwIKzJ4X2b 7RhGTtF4vyKR/Z6kfO5oZOen7PotHEwZFODxwASwkKqPIO38gnBAH3FtRDB+LClHhzAF 0tKEzV/bzfV9sj/Zz2mdzDMDayw6r/L2bDM7JoxcfLSSpcMmn3Dppb5h2KW1c6h4DNaf Vx1g== X-Gm-Message-State: AIkVDXJRkJ9JCxuNbcEdGHTTu379+YWSelloweYThu/Epl+aaUIEMiFhWRu6vOFQ/VPPYlR2Z3O9ykaS5fjlEg== X-Received: by 10.202.84.143 with SMTP id i137mr4595587oib.202.1484153493979; Wed, 11 Jan 2017 08:51:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.227.102 with HTTP; Wed, 11 Jan 2017 08:51:33 -0800 (PST) From: Hemant Singh Date: Wed, 11 Jan 2017 11:51:33 -0500 Message-ID: To: v6ops list Content-Type: multipart/alternative; boundary=001a113debb8cd1ec80545d4694f Archived-At: Subject: [v6ops] TCP related attacks/RFC3128 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 16:51:36 -0000 --001a113debb8cd1ec80545d4694f Content-Type: text/plain; charset=UTF-8 I was looking at RFC3128. It's not specific to v6ops, but being a RFC that covers TCP small fragment attacks, I thought I'd send the email. I also think, the IETF WG that sponsored this RFC may be closed now. I wonder who approved this document because it has basic mistakes. (a) In section 2.1, the document uses "Fragment A" and also "B" for the first time and does not define them anywhere. (b) In section 2, in relation to Fragment 3, the document says "Fragment offset >=2". In the IP header, the fragment offset is a multiple of 8 octets, and thus == 2 is incorrect. Please let me know if there is a current IETF WG covering such issues. Thanks, Hemant --001a113debb8cd1ec80545d4694f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I was looking at RFC3128.=C2=A0 It's not specific to v= 6ops, but being a RFC that covers TCP small fragment attacks, I thought I&#= 39;d send the email.=C2=A0 I also think, the IETF WG that sponsored this RF= C may be closed now.=C2=A0

I wonder who approved this do= cument because it has basic mistakes.

(a) In secti= on 2.1, the document uses "Fragment A" and also "B" for= the first time and does not define them anywhere.
(b) In section= 2, in relation to Fragment 3, the document says "Fragment offset >= =3D2".=C2=A0 In the IP header, the fragment offset is a multiple of 8 = octets, and thus =3D=3D 2 is incorrect.

Please let= me know if there is a current IETF WG covering such issues.

=
Thanks,

Hemant
--001a113debb8cd1ec80545d4694f-- From nobody Wed Jan 11 09:29:48 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7406012964B for ; Wed, 11 Jan 2017 09:29:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com 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 qI8jpgDdrJNk for ; Wed, 11 Jan 2017 09:29:44 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0101.outbound.protection.outlook.com [104.47.2.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03ADF1293E0 for ; Wed, 11 Jan 2017 09:29:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8lNLuZ5VJPY3aQi1f67nx6kQCEwW1zNag3ADrqGlfDo=; b=dz7xftkHd+DcygNSH+rpVIlTSdsIcOVB3pcRSx8EI/yIm09ncTlExYLYXZNvJLX87hwPXKL/OzBz3VwkMMysIkMgZkDGnL8kPXCHxTmfblSKulA7A8MvCgJUztvGMovzKOOFWIxe11/XHmVzGNgssQDdPX7km3VJMx0w4YaQ8Qk= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (81.135.210.62) by DB6PR0701MB2999.eurprd07.prod.outlook.com (10.168.84.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.845.6; Wed, 11 Jan 2017 17:29:41 +0000 Message-ID: <00dc01d26c30$0f37a260$4001a8c0@gateway.2wire.net> From: t.petch To: Ron Bonica , IPv6 Ops WG References: Date: Wed, 11 Jan 2017 17:27:54 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.135.210.62] X-ClientProxiedBy: DB5PR0101CA0042.eurprd01.prod.exchangelabs.com (10.165.200.180) To DB6PR0701MB2999.eurprd07.prod.outlook.com (10.168.84.137) X-MS-Office365-Filtering-Correlation-Id: 3cf176b1-6027-4bf8-7bf7-08d43a476d67 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:DB6PR0701MB2999; X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2999; 3:j2lwqvi5QNK3qf16ZchJxeTcn3czvJ87wEagEs2IqqrzDNVHLrebfnEMccf/snJutttibMGR4hOJdMndtdeKLAfj71AEzi1YfUiK94g5FxtIz+wkuN6mJTJaJprYSA86geYtmgRBW4xQw1xzOU1MsMpYmks7SuLQd2QTQ9IDOV7I36E5Db/SDGeHyabw8lwhgzMMfsOKp0LmsqxBpMUJTxa8kXW4Ck0DYox8bKFsRkwqqFzt8Sln9qjjZvQv8ZCW63yoYahprTXAdcadp3S2qQ==; 25:K2cX5/2xhtMBrMGgoJnM0sUdAZoKYIrNA+pwlcJC62bKs52LcIC64W2gyChKgbFNIiA0vh9+EC12w0DJmERgjNYoioKBplRELKmJNAmdSUmyBHTPD6b02249ffNkSgwVSAsNbABiMPBaAqLCz0pzPlfuyPPEWO6eFZ8aPh4M41JxCYClcQO7cuA7a+Z9LTZOS0ChP7aqtTJhyj+NGQnMHhJto572QH7mJ2uREM6ec5QVPVenlxNDqew7w0N6lHPLbS3yTFCJItkQF2002+TP4uQGUEGOwacajdUOjySoyaThc/OY6fEs8W1arndtNsdE+rj5PIiBazMBMrJQ2rgpyJ/YgNat5WL1oiQGyzznqeHH9nYRgnXz9pLDQSyvCCf/trLMfBOM54p95z5MCjfJPtovfQBjSUsUWi51r3RzdjJ7JkKrvYHcYkWKI8KLdncS8te7PlY/adYrhRCWhwzOcQ== X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2999; 31:Gu/0yasBMnyJr1GmVS1vmx496dIxCstiDI22l0m3404xwYtDPsOz9n0eljkl0TGmx/JAhKcH6lhCMBEiYx2UZwwEJbp4D6RfgJjPKaA4zatCliKHlm1gcCIoPI3AsWlG5HBPquEgdzs3zo5WeYGKdSFi57XGP2XECXl540ULv0xFR6KVULXRTEapbKhhdviTy0f1GBhIy56QYUkk47JYMBB4KkWytciDrEqvXzCNeqVh+puyTL7HeHmwrvImy7QcXYj20zeHqbDNOKFNsANwr0ngy1i2OrKntZ/H2/dj5QU=; 4:pk388vbicSFhwocNQCDm0469+C0++LZ/4HclTVMYAQeEIQfRWBWcknQmmG6UqjWr0PLqc0NCl5AshdrqgFUOBRAUJiZsmrOR/+f3dqyjX1RBcctnPrYQwPO4sj+XKd/WoAGmNU2uXX9pqSw8O3rvofmww+2F2wb/zbQ1+8SS83jNRpqXTbJ7SSEY1uoNYMIRyUO+i9QM8yiN2qiX/DmOq/33lmQK7DHPMW/UmV2oqTdu57j5uxge5fOC8OtQNNgrl4VHcnKA1h3u6+s2VxT5XmwA+047M/Spp4h/seL7ZSfEPV5t+otaufG8MqpOeE6jqb7F78+5SJwp3B/dtVTiXGTy1S1ILCWAYLNHxOnTHhWkCRTQiTaq2AKfcZVdibOWFZEr7EBo5ESwiPkm44+6kNERm64xqUHLA5GNeyT3r++tj+JCl2mHefFnPBFTcmTcR6+G4E1Jnr/mHAAWVLn+rZnDCdw90VlqbHSlVseCP1eh0zTn8zmq4y1YHe5Je08exYT7z4mTA/zNgcd1I9dtUNQnh9nRTmPOBHrhMiWCph/xLRTU+pHic1r0amm+NO64giHG5OTC255Dcd6IUGNykfJU53qgrlOaJ408nryUI0NkpUBAuFU76YTMG2WQLf/C X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(138986009662008); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(6072148); SRVR:DB6PR0701MB2999; BCL:0; PCL:0; RULEID:; SRVR:DB6PR0701MB2999; X-Forefront-PRVS: 01842C458A X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(39450400003)(189002)(199003)(13464003)(377454003)(62236002)(8666007)(44716002)(47776003)(66066001)(9686003)(1941001)(38730400001)(25786008)(6486002)(230783001)(7736002)(6496003)(2906002)(23756003)(50466002)(76176999)(1556002)(84392002)(189998001)(33646002)(4720700003)(5660300001)(6666003)(81816999)(97736004)(81166006)(8676002)(81686999)(92566002)(50226002)(5001770100001)(50986999)(14496001)(229853002)(230700001)(101416001)(1456003)(61296003)(42186005)(68736007)(44736005)(3846002)(116806002)(6116002)(107886002)(86362001)(81156014)(305945005)(106356001)(105586002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0701MB2999; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; DB6PR0701MB2999; 23:TrxjT90HFoSUcwqxvYLgOIY+5zErbT4GyIV4u?= =?iso-8859-1?Q?F4NYjE+2wUqDZRMx9Z/kE7phOVK/egJ+3Mi7ypsc27z655JCI9CywSiPD8?= =?iso-8859-1?Q?81uk/yPrg+ctugNR7dxghBffc+9t2ScQsVJ3TzS1oxheJhQT6yk6eqOMUq?= =?iso-8859-1?Q?dckhRsinjRsiH3UksS4+JaXAQzC0c1mPbjFdwdyCKYt6cw0XavOSMRxvTN?= =?iso-8859-1?Q?ouqY9HFRE8FF1WdeK3YnhUqW53sZn+VIGT/kw0yFzrIDpNous87tbqLHoF?= =?iso-8859-1?Q?r/BgeUO8rQJbKz/bti6sQhvnPCAPHeD/YXxybIwskUM1GjMalz8jMWc9WB?= =?iso-8859-1?Q?6OiPcFLstUPXt9ljmyryPYy6NEQ7cBLiqkpb11Z7l595wHPraNyBACQMkh?= =?iso-8859-1?Q?KuJKAAzoL91gAC4EQrlwAjsOZxC/M1v/KdQPjcqYpX9vWMxlaV3oL9b7/1?= =?iso-8859-1?Q?5d+Gnkyyk3AMF/daktr/OJ0nS3P/7TJzjITzYLNQt5MTSnatf6GfzCp1w6?= =?iso-8859-1?Q?n5RQhRtBUzXCn//NXKiM3PPxoiWiUC6D9RjQNatzfqBBYFXMO6yVFJVi64?= =?iso-8859-1?Q?S6f/cgjkGAH7McZ9k3VWuuZ8GnIgrwT2EpspzMCtR4NAY0NKakaLxFcssL?= =?iso-8859-1?Q?/To7WpVb2d1SE70mYGzpLYfIfrOV3I2JBtJ9fgbCKIJu4KPkqzS6OhI2fn?= =?iso-8859-1?Q?IcbVmJLbnJQvxCp8zU3WOxlTB/pf6PcWLSFT+Vv23zoUNmUCyx7S6wXbnh?= =?iso-8859-1?Q?f+/1r0GMWPoLHhWzEJICSbxJVhITSiUfOeich6T/tK/QjJg25X+v+Ymc8s?= =?iso-8859-1?Q?T965Bfqne6Kkl/l7ysAJrq2dy5IroyGHRkGwoROxxUw3Q13/uRQ7sWZ/kG?= =?iso-8859-1?Q?vJ3N5BWak1QWqmav7h8/0AhY5shjsiLs8PZRGVW9GSdoK5cvekYre20nUh?= =?iso-8859-1?Q?fRsbk1NqPQ+0to0qrHAZ/lbwvmoYmdcFnhwYY1hcjZuPmkjHs9V09SFgSF?= =?iso-8859-1?Q?TN6NT4IDLW1PXe4QEXCEydsTREJoWmW5m7vpm0Yv18gVcHoO6HmCS8w6/s?= =?iso-8859-1?Q?6w+O2bJjS3e/LwYQedhT8B6TKrA20vbENmNlTXaiQAbX6e3rfGN9p7yFnC?= =?iso-8859-1?Q?Qst17/N0lw7BuUqs/QS4SjGlvZKaBuw+qNSYLCO2+MHC303+hGDyIgS2MB?= =?iso-8859-1?Q?XJDVAHnAjn2+AT1LX2jkyGAEbOZU23/SrbkQ5lGmMFjFJQnEpTR3WKxep7?= =?iso-8859-1?Q?uOG9f/jcNmgEPzd0gJ0gM5kUBFH+OeWoTKFUNGmyk1VtUhiRdz6H1v/SYd?= =?iso-8859-1?Q?VfYBaGAn8KQCD30ZBXiY8mK/OhCdQFAGLpl/ClNK+Zhb/3MyUKSTEKeSY+?= =?iso-8859-1?Q?lT2Ryp+MGNirtGt90+FSA1ilhp6KwaibeRgWve/aMn3iegWEYo1DwV2abS?= =?iso-8859-1?Q?vutRvSSDiK5mgqd+DftjtvkfHIj8DkCLO2ZD8fRP/SvSMULKnYE3/swzQM?= =?iso-8859-1?Q?l34BhGZ0iP+1RMaKv7pVzE=3D?= X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2999; 6:fb7d8V9ch+lDJQZ9p3hZGkLZTWpMiq3LIr9IndRBVq4Q82KUv9dEODXykqob01PHAS14YMv2K+w5AcOU8KMdC4t88p5IXyVlieMDLB+epw+riyLmdlCqyzFWEO65SX1InbzNgBNufLc4YO34iqx+On2i1TiDpIJFYCj01+BvBn4zmatgdDompUudgZG3l8dCShsA3AvAUO3CkeulfSJFXSv1NXlrMPJaoTu9wrsif1r7cuGMLUV6qW2I7O5fkr19bvwQcYPe2vlnQ4eneoEfM78dGSeVa5EhWVqB4Pt5N7nRqGXcS6nwMwoxIXAHqihUSC/yX9y6lvFsgWrpoT8SppjctX/MkIm8Lo54R8aFvRbhkCbL+aSOPDFOW79IvkGjvyyQbb4c/QQBhx+QYsRXG2GvyRvCZPuERPGRZFQ4roo=; 5:N1FicqjVraCUbdDuD9lzJ3xZ24lxW5INL1zN9n3HynTxOi7YHQmA/EwbiF84EPU+SRtSBB4AleDW/kJ/EO/9PUoC+jCpRg9nplRXy9UcaF0RwiiJPi70YnCLTqLct/LraZhm17J79EzbMRXpNekbJ6AbZEHx8kEh3DifxRexyWY=; 24:nh9RydsYny4h30pPp6X8IRyHL50lK2dxCr0O2kMcRh9h3DUTjNsWEe6UVQH3PifbKB7VzllAjJSAm0PDkSFXAasOos49HHA/ns7ShfbfjV8= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2999; 7:4T1/gFff6q4SJZh0aRDmVJvvOn6rLVYMVYZ5snTg24FHJoZqup4WiDkoy1Tvoju8dHPbMTQ7FT4tAzrMr84qftTQtNvsO63+tL/s5wH2mdBkQpdzO2VCxFtcUZeepkYyzCz5IlIkB+oAQcGlUFN7RmRJ0gkK/i+X3MtZOSbLwHAwts4jX8blOtN04ppyeh54hNHhQvr6nbtNrQ64LEWIerbLPOZJh6443Z9TITCyqxIJI9cXWbmgnU0ka/m4RHmfI1KttAq7+KYkDOAcBKBfJUKfRtjzgIem7NJdyxTaVT0Dk0clC3U4f0hNC/V+L0mUyeLXn96xLGAI/7Oj0lPEfMppg2fEsSL4Y4Cw+potv1p0GcT8XnIEbTq8FcjP8Io9vDRVzRbhtQU2Xh7SvZDpXfqst5QO12+Sxd5eMh/fvZlf+KhkvHwUQEjNJprW31HUDaOd6hUChxgJhQfE1OPQuw== X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Jan 2017 17:29:41.6358 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB2999 Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 17:29:47 -0000 ---- Original Message ----- From: "Ron Bonica" To: "IPv6 Ops WG" Sent: Wednesday, January 11, 2017 3:37 PM > Folks, > > Draft-ietf-v6ops-dhcpv6-slaac-problem was introduced 3.5 years ago, but has made little progress in the last year. Therefore, it become necessary for the chairs to reevaluate whether this draft should continue to be a WG item. > > If you have an opinion on this subject, please post it to the mailing list by 1/25/17. Options are: > > 1) Continue to work on the draft with an eye toward publication in 2017 1b) Publish it as Historic Tom Petch > 2) Allow the draft to expire > > Silence or limited response will be interpreted as a lack of interest in the draft. > > Ron, Lee and Fred > > From nobody Wed Jan 11 11:20:12 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B3B41296FD for ; Wed, 11 Jan 2017 11:20:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Cwir9htleqAQ for ; Wed, 11 Jan 2017 11:20:09 -0800 (PST) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E50AE12955F for ; Wed, 11 Jan 2017 11:20:08 -0800 (PST) Received: by mail-vk0-x22b.google.com with SMTP id 137so386683059vkl.0 for ; Wed, 11 Jan 2017 11:20:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=t9j23XZjhk7VINomTW3WcOfD2z77Ad+TDcVz+YMIPNg=; b=HeaJgPL/45Aqr3urajTXhzMDiD16Ow9c1nqtV0sRnKh7MWNRt3vQmi+ExEaC+LvYJi 0E1SxrjULGHh+j7haaejOWAjb92E8BWiVQ5V7ORON6V7thHeQRY+edosV6jFCHuQRsM+ eL9f7btfE+uhthQx37y7sri5vm7ET7+8PiGq3d9T9kyKoRaTAKMyalw3Alishm6jxZ/r TpegQ0rvQO4E7O6+kylBm+GCNnNA4GeNK3T87L+sIyPdR70f10l89v1+v5QRj5ngHe6X k0L3b7H+bxTl3VscPzYYLcvyHw05jzDeD1n6bRncGkMcRQluQiud09krcY0ZjRHAZ1/h vzew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=t9j23XZjhk7VINomTW3WcOfD2z77Ad+TDcVz+YMIPNg=; b=eiWYiX+PG4C1PAUdVMypJ018wQVO5Y6Wp1it3Xw2lStQJ2YEXxV08uRhbKNRyqkibs N0QLpUapVJ1eDCen44MKGLYV9NiqxqI7HumyiA28DnVnqRZ9F7RQSr6CKUl/Rti/9k7d irwAQavD1XbaR66SWXGGvlozSiFbEOfcBwXYUl8k1rBXwoCcKhoClInmc3NwsNfWsU/7 4nX0hjRP/nEAgkRvgtYYnO9OuXEBZVtT2K8TUPi8vk4OXh8NDK83yHRMXT0ZI1Ryw6Pk U5V0Rdqe5uX10/VDnFysfg0hb5+GyiTcpjJrAvSi75przmhifgrAZ5CroqpTGDN0duQ5 HZ6Q== X-Gm-Message-State: AIkVDXJ1ogx6tJ3fYAdec2k0pW55GPZtATeNuNUMoeI1nrsUm09aldCVyCU3c/ifamYkv7t/3fNw/Xqnw7TipQ== X-Received: by 10.31.203.132 with SMTP id b126mr4015371vkg.75.1484162407949; Wed, 11 Jan 2017 11:20:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.2.235 with HTTP; Wed, 11 Jan 2017 11:20:07 -0800 (PST) Received: by 10.176.2.235 with HTTP; Wed, 11 Jan 2017 11:20:07 -0800 (PST) In-Reply-To: References: From: Mark Smith Date: Thu, 12 Jan 2017 06:20:07 +1100 Message-ID: To: Ron Bonica Content-Type: multipart/alternative; boundary=001a114dd9661d6bf20545d67d8d Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-considerations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 19:20:10 -0000 --001a114dd9661d6bf20545d67d8d Content-Type: text/plain; charset=UTF-8 Hi, I think it would should be continued to be worked on and published. I know of a Smartgrid Mesh network with around 200k+ meters on it that is using ULA addresses. However, from memory they used a single prefix shorter than a /48 rather than multiple /48s, losing random part bits. A document such as this could provide advice on scenarios such as this. Regards, Mark. On 12 Jan. 2017 2:39 am, "Ron Bonica" wrote: > Folks, > > D raft-ietf-v6ops-ula-usage-considerations was introduced 3.5 years ago, > but has made little progress in the last year. Therefore, it become > necessary for the chairs to reevaluate whether this draft should continue > to be a WG item. > > If you have an opinion on this subject, please post it to the mailing list > by 1/25/17. Options are: > > 1) Continue to work on the draft with an eye toward publication in 2017 > 2) Allow the draft to expire > > Silence or limited response will be interpreted as a lack of interest in > the draft. > > Ron, Lee and Fred > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --001a114dd9661d6bf20545d67d8d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I think = it would should be continued to be worked on and published.=C2=A0

I know of a Smartgrid Mesh networ= k with around 200k+ meters on it that is using ULA addresses. However, from= memory they used a single prefix shorter than a /48 rather than multiple /= 48s, losing random part bits. A document such as this could provide advice = on scenarios such as this.=C2=A0

Regards,
Mark.

On 12 Jan. 2017 2:39 am, "Ro= n Bonica" <rbonica@juniper.n= et> wrote:
Fo= lks,

D raft-ietf-v6ops-ula-usage-considerations was introduced 3.5 years ag= o, but has made little progress in the last year. Therefore, it become nece= ssary for the chairs to reevaluate whether this draft should continue to be= a WG item.

If you have an opinion on this subject, please post it to the mailing list = by 1/25/17. Options are:

1) Continue to work on the draft with an eye toward publication in 2017
2) Allow the draft to expire

Silence or limited response will be interpreted as a lack of interest in th= e draft.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 Ron, Lee and Fred

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--001a114dd9661d6bf20545d67d8d-- From nobody Wed Jan 11 12:10:36 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75A571297DE for ; Wed, 11 Jan 2017 12:10:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 m3uFxHKWm3-D for ; Wed, 11 Jan 2017 12:10:29 -0800 (PST) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6F2F129689 for ; Wed, 11 Jan 2017 12:10:28 -0800 (PST) Received: by mail-pf0-x22e.google.com with SMTP id y143so43782472pfb.0 for ; Wed, 11 Jan 2017 12:10:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=zblFBQ+va1sehl4Mnc/EhJYitg+VHCtHcWSePbOn7Cw=; b=igdN+3kk4w056mgLpx71rl5k0nmiZd6rI9o51m0WDv5ZfXdrDTkR3CR2yoKsghwiQa KaZSkK6oWq0TLJT7tjq86Fmjxt2HhJRVgzVfT8I+/Ag2ITlBvjsVpUsgRJpvznsCECzz 3+qfjeAdeExLq4y34OxO1EHPSTfeAJpNqwKTrCWeYJ2jezKEyFpE8yzfYLP0hxcimuRH eEcPPzyEh7jbWuQQz5lyQs8lVqkE/axPbr0csfmIu5tDZGECjSVL7M34L5ys9RdkJgHm aXX48uVxQN7TTNrpWDlPvappJ2N5BmQNE39mxJ9merCIupanv3bnqv8TQWHbdMUe/+2q hsyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=zblFBQ+va1sehl4Mnc/EhJYitg+VHCtHcWSePbOn7Cw=; b=JHEqU9TbjKneIn8kt9bBYN5JeIcaIsXSDHIk4BpIYoE3+ImZHD6jHcdXTARRFqH4tV N7QtH3ofb6kSy3fEa/BiTIJLE+Jg3sq86kEmutD5G3hB4PoWBduLkq6i/1NrfC+rtzmb Gy9nB8TZ7eDmeSKfis94ctlclLOH3JEUOwHiEq2gKoWgt2LNIb0Bj968EeAlulNOTAnZ UCaXnHFk8EpxXgdFAKoQqR7gdS7BV1UjVrgUzf2sc2K9yJ4iZ9sVRgxxz6U7VYlpqJFd MBRmz1h8jqj37CDL5HbyivQBiHAZ35/GfRu77vosryEUx4KE1sfLug9Mj5fxFI8MjAxj iWtw== X-Gm-Message-State: AIkVDXJ6E2L97GiD4c96pNNcaUijf0eu7QCl2TeFqN2UrZ3EGyONQvltIrnbfYkE8HvBdw== X-Received: by 10.99.211.21 with SMTP id b21mr13089330pgg.120.1484165428567; Wed, 11 Jan 2017 12:10:28 -0800 (PST) Received: from ?IPv6:2406:e007:45c2:1:28cc:dc4c:9703:6781? ([2406:e007:45c2:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id u124sm15872367pgb.6.2017.01.11.12.10.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Jan 2017 12:10:28 -0800 (PST) To: Hemant Singh , v6ops list References: From: Brian E Carpenter Organization: University of Auckland Message-ID: <00de884e-050b-2b64-8452-abd4f72abb7c@gmail.com> Date: Thu, 12 Jan 2017 09:10:31 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] TCP related attacks/RFC3128 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 20:10:30 -0000 Hi Hemant, The tracker shows that it was an individual draft directly submitted to the IESG, so no WG was involved. Why don't you submit errata at https://www.rfc-editor.org/errata.php ? Regards Brian On 12/01/2017 05:51, Hemant Singh wrote: > I was looking at RFC3128. It's not specific to v6ops, but being a RFC that > covers TCP small fragment attacks, I thought I'd send the email. I also > think, the IETF WG that sponsored this RFC may be closed now. > > I wonder who approved this document because it has basic mistakes. > > (a) In section 2.1, the document uses "Fragment A" and also "B" for the > first time and does not define them anywhere. > (b) In section 2, in relation to Fragment 3, the document says "Fragment > offset >=2". In the IP header, the fragment offset is a multiple of 8 > octets, and thus == 2 is incorrect. > > Please let me know if there is a current IETF WG covering such issues. > > Thanks, > > Hemant > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Wed Jan 11 12:31:20 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07EE11289B0 for ; Wed, 11 Jan 2017 12:31:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 tl3bzT5LcKVs for ; Wed, 11 Jan 2017 12:31:18 -0800 (PST) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C607129449 for ; Wed, 11 Jan 2017 12:31:18 -0800 (PST) Received: by mail-pf0-x22a.google.com with SMTP id 127so64731738pfg.1 for ; Wed, 11 Jan 2017 12:31:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=qEwgG9U4RcB7X9KKOlPZ0IG9JU2/c4F6Ndc4K3C47mI=; b=oBZACH/jNKSqNxTGMe82AJNmQBtXBcxfYnms4qbQHpPLdGy4SdnqVpgDRWA5Obrv9M uKxxQ40MbjLc2eOYWuYmSsZhJdzGr05urYU2tj8tOGO5ayw+KXc1ndYF6nPABE2Y+Lif aSyU0aqzOxRttLrfvN7pM4/A9cUT07TOe4NEFMGpYroi4gkuKA2mXUGOZnfmdhbzkYtm OGlKzekNnO9VnplmSc8SU2OjfSxbdl46rY9bC7WzXapS0h3NzUprCOulgWoCzyHzdPy1 d+0PAc9nTbZ2UtRgYnqKI9YZlUfKQcu4KEXwIfPKhG/1xHQrYsu7ZRHvjiBatmJKtRg+ s4OQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=qEwgG9U4RcB7X9KKOlPZ0IG9JU2/c4F6Ndc4K3C47mI=; b=P6jFlA+RfvnNcIojwwdOdHV7Y7/VkJC/0d47TvkdsAVfhCgYuJy1sPU8XWZT7ovBk3 +oIbbR9zatazTNyTyXYYXz80o2UTpsTZ2dkw1cqscxG8CwOPCaNRwkekwIWT6xSCt+Wu 4Xpv4N/nKDUhS+7WR6pz1J2juyKwHmvQo9fPPvcjo2S/zIs5BeCtSsEloWpAPHEXXPIp EiKa2FH8GI3P9/yDl7P/mTLzLOAERKwmmSV8aDGtWa7FW5+UmcR1LBzVBjCIN1tI0xE2 +GFmGIsPQaEpG2FRKNZvK5qm42gC3KrvUqXk1vRz89kBmqMG7Nc2OL9V5YBTGDEIk5CF o7ww== X-Gm-Message-State: AIkVDXJ/Lngo871ckMy9b+bIB1CRQY0Bpcs0/VDXVLJqjHAMr/aKnAmlRMaIXRPqWR9mtQ== X-Received: by 10.98.108.3 with SMTP id h3mr12399174pfc.65.1484166677692; Wed, 11 Jan 2017 12:31:17 -0800 (PST) Received: from ?IPv6:2406:e007:7a9f:1:28cc:dc4c:9703:6781? ([2406:e007:7a9f:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id f5sm15934710pgg.5.2017.01.11.12.31.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Jan 2017 12:31:17 -0800 (PST) To: Mark Smith , Ron Bonica References: From: Brian E Carpenter Organization: University of Auckland Message-ID: <9d5b2f04-89e6-e280-d4ef-f9f8e75ccbce@gmail.com> Date: Thu, 12 Jan 2017 09:31:19 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-considerations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 20:31:20 -0000 Agreed. ULAs just work in simple scenarios, but running with multiple prefixes should be standard practice for IPv6 so we need to tie down the loose ends. Brian On 12/01/2017 08:20, Mark Smith wrote: > Hi, > > I think it would should be continued to be worked on and published. > > I know of a Smartgrid Mesh network with around 200k+ meters on it that is > using ULA addresses. However, from memory they used a single prefix shorter > than a /48 rather than multiple /48s, losing random part bits. A document > such as this could provide advice on scenarios such as this. > > Regards, > Mark. > > On 12 Jan. 2017 2:39 am, "Ron Bonica" wrote: > >> Folks, >> >> D raft-ietf-v6ops-ula-usage-considerations was introduced 3.5 years ago, >> but has made little progress in the last year. Therefore, it become >> necessary for the chairs to reevaluate whether this draft should continue >> to be a WG item. >> >> If you have an opinion on this subject, please post it to the mailing list >> by 1/25/17. Options are: >> >> 1) Continue to work on the draft with an eye toward publication in 2017 >> 2) Allow the draft to expire >> >> Silence or limited response will be interpreted as a lack of interest in >> the draft. >> >> Ron, Lee and Fred >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Wed Jan 11 12:42:56 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6D21129449 for ; Wed, 11 Jan 2017 12:42:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Fuao5qeieCNW for ; Wed, 11 Jan 2017 12:42:53 -0800 (PST) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3436912964F for ; Wed, 11 Jan 2017 12:42:53 -0800 (PST) Received: by mail-pf0-x22f.google.com with SMTP id 127so64858798pfg.1 for ; Wed, 11 Jan 2017 12:42:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=EswqO+cxcdsfv33MFml18dNRjzp1LIC/LL+Lz+7KOKI=; b=R5mXKMOwUqgdJIy+tymuFR4a1qOOGAYjr/kzQr+Ds+TmjO3ZtRKYob4RzMX8An271Y DPief4XWSnolx3vI68zwis1dhdG5nikwLiw9zhUq7Qa7Q8s75iUfI1LUZcam0J88TZsl oNkvaLqOPa/VldUjQk220e7htUpDIOHF2t1Pf7ZKLx5oOW/sFjGlv18uZr5CaY3Qbn0Q wfA5eKnkh1knvV8CbPwqLtaPbH/Njqr9jeE6zSZReSflhX5jwKg3LrkGHPM9T3ow/Zyb 39FhtnP1/40W85L9wEDHj2/lkdLh9hjonnJLVKv4+2092kS0aUfbd5tPnOSnCYORjz3j JGkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=EswqO+cxcdsfv33MFml18dNRjzp1LIC/LL+Lz+7KOKI=; b=ipibmUqDy7ahizbeRtDRcxIKtDGbGjW8UFdCRf5EkUwm3wPpLPj7lcei4yACPArR7k DRKu0QKKnorz4+/v8SZAyRgtmC7pkgZ0617EVmSmpDEs9mL4ZlOVHBIaE/NJwdEsPOHa k23qqIhhMHsf5LsXFh2IRckygsBpuc8lpX/sRVHpopYIAVQB2joXgxkunTLfda5J+/Su VMNaLnkWvTolaQB31x22kARq2bN/hVn/e0xLOHN/9NOAfeWFdKh2VO+8UnyFKLwin9WA RWHHTl+3oC+8y1Nurd09lp/V9POOgHsHECVwk5JTw+JFbxm7gCuu6qxVOPP/JiOpTVZD sY5g== X-Gm-Message-State: AIkVDXLOQxXtqpBSfPffoHcJg3g5TGhEtm/4Bnz8CUiEC0iPdtcdNkBi7/wO5F/ptHqkeQ== X-Received: by 10.84.231.2 with SMTP id f2mr16121522plk.28.1484167372760; Wed, 11 Jan 2017 12:42:52 -0800 (PST) Received: from ?IPv6:2406:e007:7a9f:1:28cc:dc4c:9703:6781? ([2406:e007:7a9f:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id e184sm15885028pfc.28.2017.01.11.12.42.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Jan 2017 12:42:52 -0800 (PST) To: Ron Bonica , IPv6 Ops WG References: From: Brian E Carpenter Organization: University of Auckland Message-ID: <89c6a9a4-e561-dee3-8899-17ae50ae4c2a@gmail.com> Date: Thu, 12 Jan 2017 09:42:55 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 20:42:54 -0000 This draft describes real issues but the information is a bit out of date. Can we ask the authors to confirm that things are still the same for current o/s releases? Then publish quickly so that we can start the *real* discussion: how to fix? Regards Brian On 12/01/2017 04:37, Ron Bonica wrote: > Folks, > > Draft-ietf-v6ops-dhcpv6-slaac-problem was introduced 3.5 years ago, but has made little progress in the last year. Therefore, it become necessary for the chairs to reevaluate whether this draft should continue to be a WG item. > > If you have an opinion on this subject, please post it to the mailing list by 1/25/17. Options are: > > 1) Continue to work on the draft with an eye toward publication in 2017 > 2) Allow the draft to expire > > Silence or limited response will be interpreted as a lack of interest in the draft. > > Ron, Lee and Fred > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > . > From nobody Wed Jan 11 13:59:05 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88A52129D8E for ; Wed, 11 Jan 2017 13:59:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.098 X-Spam-Level: X-Spam-Status: No, score=-10.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=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 aznmkVoOhLcA for ; Wed, 11 Jan 2017 13:59:03 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F706129D80 for ; Wed, 11 Jan 2017 13:59:03 -0800 (PST) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v0BLwUVV007779 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 11 Jan 2017 13:58:31 -0800 (PST) To: Hemant Singh , v6ops list References: From: Joe Touch Message-ID: Date: Wed, 11 Jan 2017 13:58:30 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------9EDA0119CBB6971C71A6FB67" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [v6ops] TCP related attacks/RFC3128 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 21:59:04 -0000 This is a multi-part message in MIME format. --------------9EDA0119CBB6971C71A6FB67 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Hi, Hemant, On 1/11/2017 8:51 AM, Hemant Singh wrote: > I was looking at RFC3128. It's not specific to v6ops, but being a RFC > that covers TCP small fragment attacks, I thought I'd send the email. > I also think, the IETF WG that sponsored this RFC may be closed now. > > I wonder who approved this document because it has basic mistakes. > > (a) In section 2.1, the document uses "Fragment A" and also "B" for > the first time and does not define them anywhere. Presumably these refer to Fragment 1 and 2 as defined just above in the same section (end of the previous page). > (b) In section 2, in relation to Fragment 3, the document says > "Fragment offset >=2". In the IP header, the fragment offset is a > multiple of 8 octets, and thus == 2 is incorrect. The fragment offset field is indicated as a number of 8 octet units, e.g., 0=0 octets, 1=8 octets, and 2=16 octets, so that is valid. That's why the fragment field is only 13 bits long (vs. 16 bits to indicate the length of an IP datagram). > Please let me know if there is a current IETF WG covering such issues. INTAREA would be the relevant WG, but AFAICT you're pointing out something we'd probably classify as an Errata, which wouldn't need to be addressed by a WG. You can submit those here: https://www.rfc-editor.org/errata.php Joe > > Thanks, > > Hemant > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --------------9EDA0119CBB6971C71A6FB67 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi, Hemant,

On 1/11/2017 8:51 AM, Hemant Singh wrote:
I was looking at RFC3128.  It's not specific to v6ops, but being a RFC that covers TCP small fragment attacks, I thought I'd send the email.  I also think, the IETF WG that sponsored this RFC may be closed now. 

I wonder who approved this document because it has basic mistakes.

(a) In section 2.1, the document uses "Fragment A" and also "B" for the first time and does not define them anywhere.
Presumably these refer to Fragment 1 and 2 as defined just above in the same section (end of the previous page).

(b) In section 2, in relation to Fragment 3, the document says "Fragment offset >=2".  In the IP header, the fragment offset is a multiple of 8 octets, and thus == 2 is incorrect.
The fragment offset field is indicated as a number of 8 octet units, e.g., 0=0 octets, 1=8 octets, and 2=16 octets, so that is valid. That's why the fragment field is only 13 bits long (vs. 16 bits to indicate the length of an IP datagram).

Please let me know if there is a current IETF WG covering such issues.
INTAREA would be the relevant WG, but AFAICT you're pointing out something we'd probably classify as an Errata, which wouldn't need to be addressed by a WG. You can submit those here:

https://www.rfc-editor.org/errata.php

Joe


Thanks,

Hemant


_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops

--------------9EDA0119CBB6971C71A6FB67-- From nobody Wed Jan 11 16:23:33 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBA091295CF; Wed, 11 Jan 2017 16:23:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 nWLDyp91YgV8; Wed, 11 Jan 2017 16:23:30 -0800 (PST) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 519CE1295C4; Wed, 11 Jan 2017 16:23:27 -0800 (PST) Received: by mail-pf0-x22c.google.com with SMTP id f144so2381950pfa.2; Wed, 11 Jan 2017 16:23:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:message-id:date :cc:to; bh=ExN6jwxPZQIfz1Ez3/KxD0HKhtwLOLz0wO4bjqYngdQ=; b=UBRAUqG3SoqPo1qfr7X3kCpIBMCsqNchN2Pa5aQ+T9FA4dj9WT3xxM5K6lxLVTJMwv E0BVuk1BjhrYOExSErbkSGAnpYQSywt/5lrDfgAP3mcUqvD3aceZWkKjBFwIb0dAuHqc zmO3+gyss3aoNtC0wQ6781iQ684MNrNYM1ybgg+5m4hfB8y1untuWkMGSUM36+ocNPPz DrUMqfxxbUrbWj568HB1BACa29gQWGAdY4mFVh8l/rb4TEaoPJYZDoK6xcMKIY05U+MK 8/j8wmgyI2YMziYmX6wvUJgYynJkRvnRWkMzcWUSMlyTYKvk9hfAFdGm7497fkMwNdLN TVUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:cc:to; bh=ExN6jwxPZQIfz1Ez3/KxD0HKhtwLOLz0wO4bjqYngdQ=; b=YyYCGHaW9nnY7UvwFzLKXeA88m3lMNac1kyqO+PxAKVXKaMmt3KXOqQpOUlDvRXkV5 G/HsN3iDGTl60ny5iKIn7jzpdSXQgtgOwdWVX61qsFcH3Bzq7ZXFewmdqaZdZxXGXeBA aOWzuN8yxzAT/2lp6K1eDz64UInFTAOTBPCb9ryLJ8UuZbvycVLCgfrjBl2ayticLFH0 Vj1pBrZ9LRaCdTL9OdCVoiBkr0cIeEKqJDb7ScZV+8WzG7ZesEbUf7V1nou3RFlNGUX3 l+xYubzn4koPkdEQdwTuOnvXmYiRIepdyNHXof92wnOhV96OTpt5PK2LBdRZZrHdxjlf o01Q== X-Gm-Message-State: AIkVDXLLNGeJbsN+9eTNBBy0PqTAHMSVKgDkZxpd08arsWMDAstbhwe2NegYV/Gxp7dsww== X-Received: by 10.98.89.21 with SMTP id n21mr13436654pfb.163.1484180606548; Wed, 11 Jan 2017 16:23:26 -0800 (PST) Received: from [192.168.1.20] (wsip-184-191-158-59.sd.sd.cox.net. [184.191.158.59]) by smtp.gmail.com with ESMTPSA id e5sm16347021pfd.77.2017.01.11.16.23.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Jan 2017 16:23:25 -0800 (PST) From: Fred Baker Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Message-Id: Date: Wed, 11 Jan 2017 16:23:23 -0800 To: v6ops list X-Mailer: Apple Mail (2.3259) Archived-At: Cc: draft-przygienda-rift@ietf.org Subject: [v6ops] draft-przygienda-rift X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 00:23:32 -0000 The authors are looking for commentary from folks who run data centers. = At this point, the draft is not "in" any given working group, so I might = suggest commentary directly to them. Watch for redirection; it will = likely wander off to rtgwg before going anywhere else. Obvious questions I might ask, and look for operational input on, would = be what issues it raises that aren't real issues or are misunderstood, = what issues it misses, problems likely to be experienced in data centers = using it, problems in data centers that it solves well, happy faces, = etc.= From nobody Wed Jan 11 17:00:14 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C65231293F5; Wed, 11 Jan 2017 17:00:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com 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 HQRf-7M0WH_8; Wed, 11 Jan 2017 17:00:11 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0131.outbound.protection.outlook.com [104.47.42.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE51A126D74; Wed, 11 Jan 2017 17:00:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=atkw9A4m0Hx4/KChHn+UROv26cyK3+JFKugVEuu3rq8=; b=VFGZbClvunT63Np9giNu5lWYKsRwTGNR6D9NAkov5910Xl/z1HYm8uej9S2HPr+N2LcDd/P9X1IByfWfKM+y8vRzHXLUCzT12CfXi2Otw9FSmRXH7HQSgrnTaSv/0vb0YFnTUAvowcfgSVbeim0mY9QygCT30HEAaE4P8OfL2zw= Received: from BN3PR0501MB1476.namprd05.prod.outlook.com (10.160.117.20) by BN3PR0501MB1476.namprd05.prod.outlook.com (10.160.117.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.845.6; Thu, 12 Jan 2017 01:00:09 +0000 Received: from BN3PR0501MB1476.namprd05.prod.outlook.com ([10.160.117.20]) by BN3PR0501MB1476.namprd05.prod.outlook.com ([10.160.117.20]) with mapi id 15.01.0845.010; Thu, 12 Jan 2017 01:00:09 +0000 From: Antoni Przygienda To: Fred Baker , v6ops list Thread-Topic: draft-przygienda-rift Thread-Index: AQHSbGodhrbSb+KUMEurXGQ0u6fq0aEzf38A Date: Thu, 12 Jan 2017 01:00:09 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1d.0.161209 authentication-results: spf=none (sender IP is ) smtp.mailfrom=prz@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.15] x-ms-office365-filtering-correlation-id: 9eeb5cf7-63b6-4d04-c2b6-08d43a865ae2 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BN3PR0501MB1476; x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1476; 7:Fb0JNQouzb8oOM9yrjGdPq5lPshN2sFnKkYPtu6NZfC1jcXKp4y2KwEeUNtumXDTtVXbEhwQqqHwOUxCj5f0RqJ8vg3EOp4YrWJ9yPVuWZaX/mrU8OaPAkPOBiqagdqWjQG9hg1wrVx6bE8UGAKQaoLGOhwxVZ2poCFvHYDYF7logrPrZQVMZIoWuT4kRZjqw5rUhP1HSWYIDA1bIfXtcRmQ3i9UVSATEH+aDDsbM3mqnzFCoMP27a1F454UbvDVRz32IfIiUqBVEQNMyGQI/UoIx/eZS3IP3CxrWYgsHJ+JVCSDlYYFRnqLmKcFgkiqySynFcp1hHP6w/xu5g89JO2bcIQwvJM5LhWXTc0iMJMIxbnxg329rwBAPZ/Wf7KN0H0u2FNZIMSCAqc95a59JeYuigvkfstPLgWT9ii7p482NZ60dDnPmsQTMrBW1ImsEi9LSwBK0vjuxpu6Zik/Rw== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123564025)(20161123560025)(20161123555025)(6072148); SRVR:BN3PR0501MB1476; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1476; x-forefront-prvs: 018577E36E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39850400002)(39860400002)(39840400002)(39410400002)(39450400003)(66654002)(199003)(189002)(2950100002)(99286003)(3846002)(25786008)(102836003)(305945005)(68736007)(8676002)(6436002)(86362001)(230783001)(6506006)(82746002)(8936002)(3280700002)(101416001)(83716003)(7736002)(3660700001)(105586002)(122556002)(76176999)(97736004)(50986999)(83506001)(54356999)(189998001)(106356001)(6116002)(77096006)(39060400001)(38730400001)(2906002)(6486002)(81156014)(66066001)(5660300001)(81166006)(33656002)(5001770100001)(106116001)(6512007)(4001350100001)(229853002)(36756003)(2900100001)(4326007)(92566002)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1476; H:BN3PR0501MB1476.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <1F43B8A41C1BF746B1D24CDE8D44605D@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jan 2017 01:00:09.0181 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1476 Archived-At: Cc: "draft-przygienda-rift@ietf.org" Subject: Re: [v6ops] draft-przygienda-rift X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 01:00:12 -0000 RnJlZCwgbWFueSB0aGFua3MgZm9yIHBpbmdpbmcgZnVydGhlciBncm91cHMgdGhhdCBtYXkgYmUg aW50cmlndWVkLiB5ZXMsIE5WTyBhbmQgc28gb24gbWF5YmUgaW50ZXJlc3RlZCBpbiB0aGUgZHJh ZnQuIFRvIGtlZXAgdGhlIGNvbnRleHQsIHRoaXMgaXMgTk9UIGludGVuZGVkIHRvIGJlIGFuIG92 ZXJsYXkgYXBwcm9hY2ggaW4gc2Vuc2Ugb2YgRVZQTiBvciBtdWx0aS10ZW5hbmN5IG92ZXJsYXlz IG9yIExJU1Agb3IgYXR0YWNrIGdlbmVyaWMgcm91dGluZyBiZXNpZGUgdG9wb2xvZ2llcyBvZiBp bnRlcmVzdCwgdGhpcyBpcyBwdXJlbHkgdGFyZ2V0aW5nIHVuZGVybGF5IERDIHJvdXRpbmcgKHRo aW5ncyBsaWtlIFNSIG1heSBoYXZlIGltcGxpY2F0aW9ucyBzaW5jZSBURSBpcyBwYXJ0IG9mIHRo ZSByZXF1aXJlbWVudHMgd2UgZ2F0aGVyZWQpLiBXZSBiZWxpZXZlIHRoYXQgYSBzb2xpZCB1bmRl cmxheSBpcyB0aGUgZm91bmRhdGlvbiB0aGF0IHdpbGwgZ2l2ZSB5b3UgYSB0cnVlIOKAnHJlc2ls aWVudCBmYWJyaWMgd2l0aCBvcHRpbWFsIGxvYWQgYmFsYW5jaW5n4oCdIG9uIHdoaWNoIHlvdSBj YW4gZG8gYWxsIGZ1cnRoZXIgc3R1ZmYuIA0KDQpBcyB0byBhIGhvbWUsIGl0IHdpbGwgYmUgcHJl c2VudGVkIGluIHRoZSBSVEdXRyBpbnRlcmltIHRoYXQgZGVhbHMgd2l0aCB0aGUgaXNzdWUsIG5v IGZ1cnRoZXIgcGxhbnMgd2hhdHNvZXZlciByaWdodCBub3cg4oCmIA0KDQotLS0gdG9ueQ0KIA0K DQo8ZnJlZGJha2VyLmlldGZAZ21haWwuY29tPiBzcGFrZToNCg0KICAgIFRoZSBhdXRob3JzIGFy ZSBsb29raW5nIGZvciBjb21tZW50YXJ5IGZyb20gZm9sa3Mgd2hvIHJ1biBkYXRhIGNlbnRlcnMu IEF0IHRoaXMgcG9pbnQsIHRoZSBkcmFmdCBpcyBub3QgImluIiBhbnkgZ2l2ZW4gd29ya2luZyBn cm91cCwgc28gSSBtaWdodCBzdWdnZXN0IGNvbW1lbnRhcnkgZGlyZWN0bHkgdG8gdGhlbS4gV2F0 Y2ggZm9yIHJlZGlyZWN0aW9uOyBpdCB3aWxsIGxpa2VseSB3YW5kZXIgb2ZmIHRvIHJ0Z3dnIGJl Zm9yZSBnb2luZyBhbnl3aGVyZSBlbHNlLg0KICAgIA0KICAgIE9idmlvdXMgcXVlc3Rpb25zIEkg bWlnaHQgYXNrLCBhbmQgbG9vayBmb3Igb3BlcmF0aW9uYWwgaW5wdXQgb24sIHdvdWxkIGJlIHdo YXQgaXNzdWVzIGl0IHJhaXNlcyB0aGF0IGFyZW4ndCByZWFsIGlzc3VlcyBvciBhcmUgbWlzdW5k ZXJzdG9vZCwgd2hhdCBpc3N1ZXMgaXQgbWlzc2VzLCBwcm9ibGVtcyBsaWtlbHkgdG8gYmUgZXhw ZXJpZW5jZWQgaW4gZGF0YSBjZW50ZXJzIHVzaW5nIGl0LCBwcm9ibGVtcyBpbiBkYXRhIGNlbnRl cnMgdGhhdCBpdCBzb2x2ZXMgd2VsbCwgaGFwcHkgZmFjZXMsIGV0Yy4NCg0K From nobody Wed Jan 11 18:04:08 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46604129431 for ; Wed, 11 Jan 2017 18:04:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.099 X-Spam-Level: X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=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 B5A1rTqbpqCz for ; Wed, 11 Jan 2017 18:03:59 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 950D212949B for ; Wed, 11 Jan 2017 18:03:59 -0800 (PST) Received: from mb-3.local ([IPv6:2601:647:4201:9e61:6551:162f:1003:ba81]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id v0C23uuK060150 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 12 Jan 2017 02:03:57 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host [IPv6:2601:647:4201:9e61:6551:162f:1003:ba81] claimed to be mb-3.local To: Ron Bonica , IPv6 Ops WG References: From: joel jaeggli Message-ID: <67b3af77-3ab6-95f2-93c5-45d036efb935@bogus.com> Date: Wed, 11 Jan 2017 18:03:54 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:50.0) Gecko/20100101 Thunderbird/50.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="B4HRWegEoSkuoednBQnGvCEeMwvIXwRaM" Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-considerations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 02:04:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --B4HRWegEoSkuoednBQnGvCEeMwvIXwRaM Content-Type: multipart/mixed; boundary="0lhsQsNQpPfgnube3IhcosN7JJCc8h7BO"; protected-headers="v1" From: joel jaeggli To: Ron Bonica , IPv6 Ops WG Message-ID: <67b3af77-3ab6-95f2-93c5-45d036efb935@bogus.com> Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-considerations References: In-Reply-To: --0lhsQsNQpPfgnube3IhcosN7JJCc8h7BO Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: quoted-printable For me personally, the presence of npt6 or indeed any form of ula only deployment, save perhaps for ephemeral private networks is a bright line not to be crossed. I find it hard to support a document that treats the subject without recommending never to do those things. joel On 1/11/17 7:39 AM, Ron Bonica wrote: > Folks, >=20 > D raft-ietf-v6ops-ula-usage-considerations was introduced 3.5 years ago= , but has made little progress in the last year. Therefore, it become nec= essary for the chairs to reevaluate whether this draft should continue to= be a WG item. >=20 > If you have an opinion on this subject, please post it to the mailing l= ist by 1/25/17. Options are: >=20 > 1) Continue to work on the draft with an eye toward publication in 2017= > 2) Allow the draft to expire >=20 > Silence or limited response will be interpreted as a lack of interest i= n the draft. >=20 > Ron, Lee and Fred >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 --0lhsQsNQpPfgnube3IhcosN7JJCc8h7BO-- --B4HRWegEoSkuoednBQnGvCEeMwvIXwRaM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlh25AsACgkQ8AA1q7Z/VrJ0iACfYXoDxnbl89unBXjw+u6E5ByI KnsAni6Avbl4MjtQjmUXHrsZczaiznBT =uwds -----END PGP SIGNATURE----- --B4HRWegEoSkuoednBQnGvCEeMwvIXwRaM-- From nobody Wed Jan 11 18:08:20 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62DFE129455 for ; Wed, 11 Jan 2017 18:08:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.42 X-Spam-Level: X-Spam-Status: No, score=-7.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 m3h34DTzaRtz for ; Wed, 11 Jan 2017 18:08:16 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C617D129458 for ; Wed, 11 Jan 2017 18:08:15 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DEG67322; Thu, 12 Jan 2017 02:08:13 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 12 Jan 2017 02:08:12 +0000 Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Thu, 12 Jan 2017 10:08:07 +0800 From: "Liubing (Leo)" To: Brian E Carpenter , Ron Bonica , IPv6 Ops WG Thread-Topic: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem Thread-Index: AdJsHl8ei2TWu3IlRCWkCcSkighPWf//07eA//8hRvA= Date: Thu, 12 Jan 2017 02:08:07 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45C2E96D26@nkgeml514-mbx.china.huawei.com> References: <89c6a9a4-e561-dee3-8899-17ae50ae4c2a@gmail.com> In-Reply-To: <89c6a9a4-e561-dee3-8899-17ae50ae4c2a@gmail.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.191.175] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.5876E50E.0008, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: fabef7d47426ae4b732fe11333ec7a65 Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 02:08:18 -0000 Hi Brian, -----Original Message----- From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Brian E Carpenter Sent: Thursday, January 12, 2017 4:43 AM To: Ron Bonica; IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem This draft describes real issues but the information is a bit out of date. Can we ask the authors to confirm that things are still the same for curren= t o/s releases?=20 [Bing] I think even if the latest OSes have been changed to have the same b= ehavior, the problem is still existing, since some older versions (e.g. Win= dow 7) might last for a long time.=20 Anyway, if the WG still think the draft is worth to be published, then no p= roblem for us to do the tests on the latest OSes and update the draft. Best regards, Bing Then publish quickly so that we can start the *real* discussion: how to fix? Regards Brian On 12/01/2017 04:37, Ron Bonica wrote: > Folks, >=20 > Draft-ietf-v6ops-dhcpv6-slaac-problem was introduced 3.5 years ago, but h= as made little progress in the last year. Therefore, it become necessary fo= r the chairs to reevaluate whether this draft should continue to be a WG it= em. >=20 > If you have an opinion on this subject, please post it to the mailing lis= t by 1/25/17. Options are: >=20 > 1) Continue to work on the draft with an eye toward publication in=20 > 2017 > 2) Allow the draft to expire >=20 > Silence or limited response will be interpreted as a lack of interest in = the draft. >=20 > Ron, Lee and Fred >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > . >=20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Jan 11 18:36:52 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C430C129401 for ; Wed, 11 Jan 2017 18:36:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jvknet-com.20150623.gappssmtp.com 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 sb2Qfeehfq2R for ; Wed, 11 Jan 2017 18:36:49 -0800 (PST) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8462126BF7 for ; Wed, 11 Jan 2017 18:36:48 -0800 (PST) Received: by mail-vk0-x22e.google.com with SMTP id r136so4249351vke.1 for ; Wed, 11 Jan 2017 18:36:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jvknet-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WghfToena8EJtj2ASoRA1dXaq0XDrUPx3DBLScYq2Rs=; b=MVx8Hsztf9YSoe0JXpD/GtAYDQmJDyyFF7RceL+KiYA+pABvLVkUGsfcntfl0xYz8j CpGAbNdgboizUf+3jZLvx91TCv4/z6OAVyTaXVaVGq71+qXOoLRTLrQ0bVKHa323mdLS Z/bMcA2ycwDBjif734G7/Dz//5Z2Jg/YXWHvsitETxMmXq0E3aAppeatezFgb1NFnVnk fW95uz8B3ScVj/Zkc0K2/VL3/t9PkQSJYjuAyFS3mNbcEf5YWkZeFqcROhL77QIYWOaW 1XIi6y/w8S9hPcSRHXZ/VznL9xPAhCFY5mYzawLfmsAR7MKjBk5aOnd0C0yHgSemK7J7 KqsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WghfToena8EJtj2ASoRA1dXaq0XDrUPx3DBLScYq2Rs=; b=S1Z6AYg8EXM6jjz0WRXkyUzBdDJyoLanJtWG4ZEd3MoQsaQj369J/frOxvZHgiLLLm I5ZZqErsKizY9aWuknKE2+5h3uR1O/XNveKW+Ct1v+Pluj19/Fb38/9+cqLmb1graMAF P+8UJa1hNgCe+CWX84PD72lBoCc444zsY4xv2cnnrsbKcF109MPpiVbh15KfqTaAY9JN PyZ0YEXaV1CmX31g+U6OjcLe/6Lyk+CaXQwrN4ZgP80jAiUnszTUzjQvowlbJG8LNm7f 9pTQRRVI1oJAHnoG3XnAl5hulHhEN/ttQBawoHXED+rmI9Rp5MARN/IxkYwliDOK3DXH iHcA== X-Gm-Message-State: AIkVDXKe/wmnyhp3NKaKaIdBooGW3FnD3AOohd6zjuT6bu6KF+nXL1sLuRk+25SynbT5SYRkOXrpVed9foen1Q== X-Received: by 10.31.225.69 with SMTP id y66mr5751463vkg.18.1484188607923; Wed, 11 Jan 2017 18:36:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.235.195 with HTTP; Wed, 11 Jan 2017 18:36:47 -0800 (PST) In-Reply-To: References: From: Victor Kuarsingh Date: Wed, 11 Jan 2017 21:36:47 -0500 Message-ID: To: Ron Bonica Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-considerations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 02:36:51 -0000 Ron, et al, I would go for option 1, but with modifications to content of draft. My perspective is that there is utility in describing real world [valid] use cases of ULAs, however, avoiding statements of scenarios which we know are problematic (unless we specifically describe the situation/use case, then note - "this is considered to be harmful" or preferably text which explains why it's limiting or harmful) Given ULAs are out there, and more networks may wind up having them inserted, providing information on usage of such addresses (especially noting known issues) may help avoid inappropriate use of such addresses. Sure, some may still do it, but we can't stop that. Use cases such as ULAs in Isolated networks (and/or nodes/hosts which have no Internet connectivity requirements) is a valid use case in my mind and we have working examples where this can be valuable in networks. There are however uses cases in section 4.2.1 and 4.2.2 which can still be described, but perhaps we should spend less text discussing the benefits here and stress the drawbacks (e.g. "Ease of Management" as a support to use ULAs is weak as a need to use them, and given it would then need some form of translation to connect those hosts to the Internet is adding more burden then benefit by my calculations). Just because we know the issues people can get themselves into with using ULAs should not limit us form documenting good/valid uses of such and also highlighting the dangers of other cases. regards, Victor K On Wed, Jan 11, 2017 at 10:39 AM, Ron Bonica wrote: > Folks, > > D raft-ietf-v6ops-ula-usage-considerations was introduced 3.5 years ago, but has made little progress in the last year. Therefore, it become necessary for the chairs to reevaluate whether this draft should continue to be a WG item. > > If you have an opinion on this subject, please post it to the mailing list by 1/25/17. Options are: > > 1) Continue to work on the draft with an eye toward publication in 2017 > 2) Allow the draft to expire > > Silence or limited response will be interpreted as a lack of interest in the draft. > > Ron, Lee and Fred > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Jan 11 18:52:12 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71AC912946C for ; Wed, 11 Jan 2017 18:52:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 cexa2ZhK8km4 for ; Wed, 11 Jan 2017 18:52:10 -0800 (PST) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EFD0129461 for ; Wed, 11 Jan 2017 18:52:10 -0800 (PST) Received: by mail-pf0-x236.google.com with SMTP id 189so4410333pfu.3 for ; Wed, 11 Jan 2017 18:52:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=h6UmSGNkU4LYvMZtyH6lfXsdYU6ZuU3ZAtrdlcx7YuA=; b=gJPJxGI0nxejsabzJlBvre4u94Tt+pyAuhirhGxGEZaSDDf2nf5jgWfLYPtoCBTx0c 8LETvMLXqAyU82ic0c6Z1Hm6QBdSrhslyQq8TWXvC3hKINjCdKghl7+Jxb8QbKN9JvUg vP34NzJlkAWE2zwqXdm6JpayCyveOsKarFFq+js70aAdT+b20Lw4r0RJ32rYr76JBqGN NaSZAFY2JFN9/6RcnhJVrbBBKhWbdFqHS5lu43z2JO/y/OmenU1X35DRLl7rV52G8TMa 3tAtKXuAIjOfXbV5g1d68u9rzUlHJ6pwzV9zm4mOxHW/aLI1hRZCkuqiWrLHNHBf0cqc MUsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=h6UmSGNkU4LYvMZtyH6lfXsdYU6ZuU3ZAtrdlcx7YuA=; b=O39+TJ8MiNuPY6QeA1Xz8Nla64p/MMqitrOqie7SSxbmbcSDSENGwVidTOCVmwIj3v MwlMWAsTrmP5XVV92OIbmEANSzE9DXKgYVrWRrdKqlrPDB3J6Wm90P8wurOnWWRTb22X enGNCeNhDO3wV4M248sUWiGB0N/TSP5tVtY8fHe8xoxdrFmseAv+dnXkUtcPn3rpqsF7 AcxnfGYqM3029wZjF7nzuicovwPCHgH279SVPdGfkXP0kjriyvoR8yENJQi37LG0i1Ho msnTTuqX+7PTAaxacuXGdYAjGjzvelwRMUwLhTj+aEJokq4tPgrpvBh5h+cOUH0n4dSi 7Z3g== X-Gm-Message-State: AIkVDXJZcG1BRJ4YlRf6P4bo5SOsUl5/WQzx5Cxsv/tlfWfRKnLL1rzj4YR+obOStvDdXA== X-Received: by 10.99.54.79 with SMTP id d76mr14415891pga.91.1484189529559; Wed, 11 Jan 2017 18:52:09 -0800 (PST) Received: from ?IPv6:2406:e007:611f:1:28cc:dc4c:9703:6781? ([2406:e007:611f:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id a2sm16806957pgn.24.2017.01.11.18.52.08 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Jan 2017 18:52:09 -0800 (PST) To: v6ops@ietf.org References: <67b3af77-3ab6-95f2-93c5-45d036efb935@bogus.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <048a00cd-ff4f-abd8-cc15-36df70964748@gmail.com> Date: Thu, 12 Jan 2017 15:52:12 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <67b3af77-3ab6-95f2-93c5-45d036efb935@bogus.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-considerations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 02:52:11 -0000 On 12/01/2017 15:03, joel jaeggli wrote: > For me personally, the presence of npt6 or indeed any form of ula only > deployment, save perhaps for ephemeral private networks is a bright > line not to be crossed. I find it hard to support a document that treats > the subject without recommending never to do those things. I agree with that and with Victor's comment. But do you think we could elevate this to BCP? I'm not comfortable that we have enough experience to do that. Brian > > joel > > On 1/11/17 7:39 AM, Ron Bonica wrote: >> Folks, >> >> D raft-ietf-v6ops-ula-usage-considerations was introduced 3.5 years ago, but has made little progress in the last year. Therefore, it become necessary for the chairs to reevaluate whether this draft should continue to be a WG item. >> >> If you have an opinion on this subject, please post it to the mailing list by 1/25/17. Options are: >> >> 1) Continue to work on the draft with an eye toward publication in 2017 >> 2) Allow the draft to expire >> >> Silence or limited response will be interpreted as a lack of interest in the draft. >> >> Ron, Lee and Fred >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Wed Jan 11 21:13:12 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47CFB12941E for ; Wed, 11 Jan 2017 21:13:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 KtIFOfCQGurf for ; Wed, 11 Jan 2017 21:13:08 -0800 (PST) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CF21126FDC for ; Wed, 11 Jan 2017 21:13:08 -0800 (PST) Received: by mail-ua0-x229.google.com with SMTP id i68so6686632uad.0 for ; Wed, 11 Jan 2017 21:13:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oLXEJ62fwTImjqwJP2P3PZ8eax/kMtD55E740EUW2CI=; b=TeCVE0Arm5d7qz0CNT9KIBc9Ld/Z0zwogcNA/QW1XB8t0KGMGQNpL/A8e4MUw317a9 zyVKSZ/I8+STDwMjZu1w/r6UmlKzanAMO36uDJjBChDsIRsH5WmEIq0dr80HrjrBNAg5 bAiD+VjDWo5GXp79faLOxK59yocFlRSyc9O/v1C0sYox56rT/U4mOfY3Er4Vnui0SfEm 54s1J/WJf5Ock3r8lQiDpwPj96WqhCc8L0hvJNourroiAPq0ByzODFhfkvu7OS7pQZjG rHCCxjJgdsx9ENqVwEFhnhvzpCbJiGCN40oO6uDZdTDszFeMh/8DPAX4uMl9jnreeIS7 ZOZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oLXEJ62fwTImjqwJP2P3PZ8eax/kMtD55E740EUW2CI=; b=ta5M0k7OhSEeq8MQgqRcw9kPkAuxQtssdHrZlB3CIgTrYAeMUR66EgHMlcxFowet/p o8w92XKfI5CklS9M+yUUgT73YyWlVDmLkTGSSw4HarsbhsPMCfM4ahm4VY2Cl0a/NXCM TxBnEb1/wH2HuQDuSBU2UILJr0YHGYDDyzWv2PgKQrYSTUyQiqMCbZH6HVvAyPJ92NnM IzLad8L4hSbG/aW3DYNPSIHDWxor0Ucuykm+YwBFVin8ThIinVb1NZ4ZUEYWJJSp97rd XKBLsiHTAv0uHV+YJLjd/w91NYm+6fk47YHBZqs+qYf+sVAELd0h6r4gsVXgKfG+0Rgl 7XcA== X-Gm-Message-State: AIkVDXIX6FseDryoAesFY96PR9zbIIrmmlOKwJ6M7m/cd4EWu8rNqWF0maOm57bUkg6XIBNEZKbj6d5MiHnYuoik X-Received: by 10.176.5.138 with SMTP id e10mr5369907uae.109.1484197987256; Wed, 11 Jan 2017 21:13:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.49.77 with HTTP; Wed, 11 Jan 2017 21:12:46 -0800 (PST) In-Reply-To: <67b3af77-3ab6-95f2-93c5-45d036efb935@bogus.com> References: <67b3af77-3ab6-95f2-93c5-45d036efb935@bogus.com> From: Lorenzo Colitti Date: Thu, 12 Jan 2017 14:12:46 +0900 Message-ID: To: joel jaeggli Content-Type: multipart/alternative; boundary=94eb2c124794cedab30545dec589 Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-considerations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 05:13:10 -0000 --94eb2c124794cedab30545dec589 Content-Type: text/plain; charset=UTF-8 Right. ULA-only deployments and (worse) ULA+NPTv6 for multihoming are very contentious points and are part of the reason this document has been around for so long. Some WG participants, including the authors would like to document these scenarios, but other participants (not just Joel; I remember quite a line at the mike in Yokohama, and I was one of them) are not willing to see this document published without strong language recommending against such deployments. I don't think the people who oppose ULA-only deployments have changed their minds in any meaningful way since then. It's possible that this time around it will be easier to reach a compromise, but I wouldn't bet on it. I agree with Brian that we don't have enough operational experience for this document to be a BCP. There are no case studies in this document, and I am not aware of any publicly-available operational reports of substantial ULA deployments. On Thu, Jan 12, 2017 at 11:03 AM, joel jaeggli wrote: > For me personally, the presence of npt6 or indeed any form of ula only > deployment, save perhaps for ephemeral private networks is a bright > line not to be crossed. I find it hard to support a document that treats > the subject without recommending never to do those things. > > joel > > On 1/11/17 7:39 AM, Ron Bonica wrote: > > Folks, > > > > D raft-ietf-v6ops-ula-usage-considerations was introduced 3.5 years > ago, but has made little progress in the last year. Therefore, it become > necessary for the chairs to reevaluate whether this draft should continue > to be a WG item. > > > > If you have an opinion on this subject, please post it to the mailing > list by 1/25/17. Options are: > > > > 1) Continue to work on the draft with an eye toward publication in 2017 > > 2) Allow the draft to expire > > > > Silence or limited response will be interpreted as a lack of interest in > the draft. > > > > Ron, Lee and Fred > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --94eb2c124794cedab30545dec589 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Right. ULA-only deployments and (worse) ULA+NPTv6 for mult= ihoming are very contentious points and are part of the reason this documen= t has been around for so long.

Some WG participants, inc= luding the authors would like to document these scenarios, but other partic= ipants (not just Joel; I remember quite a line at the mike in Yokohama, and= I was one of them) are not willing to see this document published without = strong language recommending against such deployments.

I= don't think the people who oppose ULA-only deployments have changed th= eir minds in any meaningful way since then. It's possible that this tim= e around it will be easier to reach a compromise, but I wouldn't bet on= it.

I agree with Brian that we don't ha= ve enough operational experience for this document to be a BCP. There are n= o case studies in this document, and I am not aware of any publicly-availab= le operational reports of substantial ULA deployments.

On Thu, Jan 12, 2017 at 11= :03 AM, joel jaeggli <joelja@bogus.com> wrote:
For me personally, the presence of npt6 or indeed any f= orm of ula only
deployment, save=C2=A0 perhaps for ephemeral private networks is a bright line not to be crossed. I find it hard to support a document that treats the subject without recommending never to do those things.

joel

On 1/11/17 7:39 AM, Ron Bonica wrote:
> Folks,
>
> D raft-ietf-v6ops-ula-usage-considerations was introduced 3.5 yea= rs ago, but has made little progress in the last year. Therefore, it become= necessary for the chairs to reevaluate whether this draft should continue = to be a WG item.
>
> If you have an opinion on this subject, please post it to the mailing = list by 1/25/17. Options are:
>
> 1) Continue to work on the draft with an eye toward publication in 201= 7
> 2) Allow the draft to expire
>
> Silence or limited response will be interpreted as a lack of interest = in the draft.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0Ron, Lee and Fred
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops=
>



_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops


--94eb2c124794cedab30545dec589-- From nobody Thu Jan 12 00:45:16 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39C831293E1 for ; Thu, 12 Jan 2017 00:45:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.264 X-Spam-Level: ** X-Spam-Status: No, score=2.264 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_SORBS_WEB=3.599, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 LVbAPjnROgDp for ; Thu, 12 Jan 2017 00:45:13 -0800 (PST) Received: from esa01.kjsl.com (esa01.kjsl.com [198.137.202.87]) by ietfa.amsl.com (Postfix) with ESMTP id 74D6B12896F for ; Thu, 12 Jan 2017 00:45:13 -0800 (PST) Received: from cowbell.employees.org ([65.50.211.142]) by esa01.kjsl.com with ESMTP; 12 Jan 2017 08:45:12 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 96C519CC81; Thu, 12 Jan 2017 00:45:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s= selector1; bh=KdXE48FS0fLkms08R+d9N98yoFk=; b=W8bR1CaIlq+FVXpgBg IyBXeHf6SA+d23AKm1rhCFDrITy01FPo5o2dTiaDCTXw21F8gGlVhNsJiV+i+oyM AiHMSCg1BwC/u018MNJKNj51eU/egy9N5bFWojady/gvsisQNgJ+1d9o6ccf5Ra/ m0syKoMj7je/ugA5XEbIDod3I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; q=dns; s= selector1; b=j2++zvFoRxFvdcRdHSvwwF4xtGkZV5t5/sKoZWl/JwlYjseRAMh 1flE+dDlDQxkFvovvAam5tTtvMlUrm1GssAxzOD44QlpfRnwhwmXJDIOZ0tmK5/5 eECGHOaDkM5CAfoBammJceFzj/HW69GNnLCyjLX1y7/f1F3h4ci3m+PI= Received: from h.hanazo.no (219.103.92.62.static.cust.telenor.com [62.92.103.219]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 61F1B9CC84; Thu, 12 Jan 2017 00:45:12 -0800 (PST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id AD8D174632F5; Thu, 12 Jan 2017 09:45:08 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: otroan@employees.org In-Reply-To: <89c6a9a4-e561-dee3-8899-17ae50ae4c2a@gmail.com> Date: Thu, 12 Jan 2017 09:45:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <44FCCC34-7995-4E10-85E9-58C08C371416@employees.org> References: <89c6a9a4-e561-dee3-8899-17ae50ae4c2a@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3259) Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 08:45:14 -0000 > This draft describes real issues but the information is a bit out of = date. > Can we ask the authors to confirm that things are still the same for = current > o/s releases? Then publish quickly so that we can start the *real* = discussion: > how to fix? This draft shouldn't be gating any real discussion. If there are = solutions please offer them now. I have read through the draft again. While the draft has some points, = these are issues that has been discussed extensively. I struggle to see = how this will lead to and "fixes". I have a suggestion. Given that we have beaten on this particular horse = a lot over the last 15 years. Could we redo this draft into a "Why?" draft in the style of RFC7421? Explain the issues, explain the design choices and why the mechanisms = function as they do, but don't phrase it as a problem that needs to be = fixed. Best regards, Ole From nobody Thu Jan 12 01:39:01 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D4141294EE for ; Thu, 12 Jan 2017 01:39:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 hVtLVZlh3bfb for ; Thu, 12 Jan 2017 01:38:58 -0800 (PST) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8A5E1294E5 for ; Thu, 12 Jan 2017 01:38:58 -0800 (PST) Received: by mail-ua0-x22e.google.com with SMTP id i68so10247329uad.0 for ; Thu, 12 Jan 2017 01:38:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0H4UteDX2BGYHWPraTRg7SfTOzZeNQ2o7tkal9Dm7+Y=; b=Hpk15pmx8mkd4H/Hixl+fMOQ4CCM+qomyjLdsEjegf/P1RXNyttdYXu1BJseMrNkCi wc5CrCXJkegihEJ7CZeMtKk2FSreSAVrkQuD/nNYNYRqMj/QOdNKpNOkPrqjb4gj7cyx IW8SsTUvmDfcnpl2LCP4gzeJsMTXRrMhRMkxrZ5hMgu4hAMgHPNhlu9IzLpxfZH4Rlbj MvUffrbvIwddXoeNKCVD7LqH/DIlOTk+NN+XGjHay95UVT8b3YQ/OeCjIkYPeNTVzKYo EHlXsTDqwSh+BCyLZtAJkA940UmiskEQg/vlaWQm9cSpgXIwwYv6K/zGBKVt2fv49Sy0 9xbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0H4UteDX2BGYHWPraTRg7SfTOzZeNQ2o7tkal9Dm7+Y=; b=ji0cAu/iyb5HhSAi6Xkyju+FzBi1+mB2PYXEeyAS1rf47Sy70XwmH1hvTCAk4LDei1 /jEVpgawfCMDw1Zf1v9lQ+f01VQgJs0l5wugG+dBxzK581DOaVwxh3XtkzPHwVpgm96W lFEkaiXFFcmcMyFaR5BSGrVJl6HeAP8rBCyko/KwbyLmDaV9rDAXKurbxPeA3KRCo7uD yXrYv5Nm4R59/ZsNf7Wa2kKKCvxUiGZOG3lI2yKnWKTfpM65BMEqVYqovrlBP7ighRRe uH9LBeJu/Jl8mwNBJZ+g9Dnqvnfzh1lOcr9G0FVK7SvYwuoPXUSzKfbHsYcTE73AY89e mS2Q== X-Gm-Message-State: AIkVDXIQs09zgHa8eXaqVHVqnus1si4r4C3GFw83HjJaZeDlkSzs2hROnOl1Z9X96xo/RQyECfdrV0asF7Mn/w== X-Received: by 10.159.48.131 with SMTP id j3mr5554949uab.43.1484213937675; Thu, 12 Jan 2017 01:38:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.2.235 with HTTP; Thu, 12 Jan 2017 01:38:56 -0800 (PST) Received: by 10.176.2.235 with HTTP; Thu, 12 Jan 2017 01:38:56 -0800 (PST) In-Reply-To: <67b3af77-3ab6-95f2-93c5-45d036efb935@bogus.com> References: <67b3af77-3ab6-95f2-93c5-45d036efb935@bogus.com> From: Mark Smith Date: Thu, 12 Jan 2017 20:38:56 +1100 Message-ID: To: joel jaeggli Content-Type: multipart/alternative; boundary=f403045e351086a0d50545e27c1a Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-considerations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 09:39:00 -0000 --f403045e351086a0d50545e27c1a Content-Type: text/plain; charset=UTF-8 On 12 Jan. 2017 1:04 pm, "joel jaeggli" wrote: For me personally, the presence of npt6 or indeed any form of ula only deployment, save perhaps for ephemeral private networks is a bright line not to be crossed. I find it hard to support a document that treats the subject without recommending never to do those things. I'm nearly in entire agreement with that. The specific use case I was referring to is an AMI smartgrid network with the meters only having a ULA address. They never should be reachable from the Internet, and only need to be reachable to/from their management applications. Providing them with GUAs, even if protected by a network firewall somewhere, creates the possibility of reachability to/from the Internet, which is an unacceptable risk. Although hosts having and choosing between multiple addresses increases complexity, I think the ability to create domains of different reachability based on address types is a useful security feature. If a host is to have global and local network reachability, give it a GUA and ULA address. Local reachability only; a ULA only, no GUA. Link only; a link local address only. Alternatively, applications can make that choice by choosing which address type(s) to use to connect with, or to listen to and accept connections from. Regards, Mark. joel On 1/11/17 7:39 AM, Ron Bonica wrote: > Folks, > > D raft-ietf-v6ops-ula-usage-considerations was introduced 3.5 years ago, but has made little progress in the last year. Therefore, it become necessary for the chairs to reevaluate whether this draft should continue to be a WG item. > > If you have an opinion on this subject, please post it to the mailing list by 1/25/17. Options are: > > 1) Continue to work on the draft with an eye toward publication in 2017 > 2) Allow the draft to expire > > Silence or limited response will be interpreted as a lack of interest in the draft. > > Ron, Lee and Fred > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops --f403045e351086a0d50545e27c1a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 12 Jan. 2017 1:04 pm, "joel jaeggli" <joelja@bogus.com> wrote:
For me personally, the presence of npt6 or i= ndeed any form of ula only
deployment, save=C2=A0 perhaps for ephemeral private networks is a bright line not to be crossed. I find it hard to support a document that treats the subject without recommending never to do those things.

I'm nearly in entire agreement with th= at.=C2=A0

The specific u= se case I was referring to is an AMI smartgrid network with the meters only= having a ULA address. They never should be reachable from the Internet, an= d only need to be reachable to/from their management applications. Providin= g them with GUAs, even if protected by a network firewall somewhere, create= s the possibility of reachability to/from the Internet, which is an unaccep= table risk.

Although hos= ts having and choosing between multiple addresses increases complexity, I t= hink the ability to create domains of different reachability based on addre= ss types is a useful security feature.

If a host is to have global and local network reachability, = give it a GUA and ULA address. Local reachability only; a ULA only, no GUA.= Link only; a link local address only.

Alternatively, applications can make that choice by choosing= which address type(s) to use to connect with, or to listen to and accept c= onnections from.

Regards= ,=C2=A0
Mark.






joel

On 1/11/17 7:39 AM, Ron Bonica wrote:
> Folks,
>
> D raft-ietf-v6ops-ula-usage-considerations was introduced 3.5 yea= rs ago, but has made little progress in the last year. Therefore, it become= necessary for the chairs to reevaluate whether this draft should continue = to be a WG item.
>
> If you have an opinion on this subject, please post it to the mailing = list by 1/25/17. Options are:
>
> 1) Continue to work on the draft with an eye toward publication in 201= 7
> 2) Allow the draft to expire
>
> Silence or limited response will be interpreted as a lack of interest = in the draft.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0Ron, Lee and Fred
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops=
>



_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops


--f403045e351086a0d50545e27c1a-- From nobody Thu Jan 12 01:51:59 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03A8E1294C8 for ; Thu, 12 Jan 2017 01:51:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 jitY56YaX415 for ; Thu, 12 Jan 2017 01:51:56 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E3B5127058 for ; Thu, 12 Jan 2017 01:51:56 -0800 (PST) Received: from [192.168.3.88] (142-135-17-190.fibertel.com.ar [190.17.135.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id B0DD982C32; Thu, 12 Jan 2017 10:51:52 +0100 (CET) To: Ron Bonica , IPv6 Ops WG References: From: Fernando Gont Message-ID: <8d84eb92-17b0-7563-7f8b-12cbe72b1bf0@si6networks.com> Date: Thu, 12 Jan 2017 06:45:17 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 09:51:58 -0000 On 01/11/2017 12:37 PM, Ron Bonica wrote: > Folks, > > Draft-ietf-v6ops-dhcpv6-slaac-problem was introduced 3.5 years ago, > but has made little progress in the last year. Therefore, it become > necessary for the chairs to reevaluate whether this draft should > continue to be a WG item. > > If you have an opinion on this subject, please post it to the mailing > list by 1/25/17. Options are: > > 1) Continue to work on the draft with an eye toward publication in > 2017 I'm with option "1)" (publish) Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Jan 12 01:52:25 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2FB12953F for ; Thu, 12 Jan 2017 01:52:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 pa_WTego-3rs for ; Thu, 12 Jan 2017 01:52:04 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63F1412953E for ; Thu, 12 Jan 2017 01:52:04 -0800 (PST) Received: from [192.168.3.88] (142-135-17-190.fibertel.com.ar [190.17.135.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 1E6A0836C0; Thu, 12 Jan 2017 10:52:00 +0100 (CET) To: Brian E Carpenter , Ron Bonica , IPv6 Ops WG References: <89c6a9a4-e561-dee3-8899-17ae50ae4c2a@gmail.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <737ab45e-0323-2653-f6d6-39268a393625@si6networks.com> Date: Thu, 12 Jan 2017 06:47:01 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <89c6a9a4-e561-dee3-8899-17ae50ae4c2a@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 09:52:09 -0000 On 01/11/2017 05:42 PM, Brian E Carpenter wrote: > This draft describes real issues but the information is a bit out of > date. Can we ask the authors to confirm that things are still the > same for current o/s releases? Then publish quickly so that we can > start the *real* discussion: how to fix? I'd agree with Brian. -- but also please keep the data for the OS releases/versions listed in the I-D. All of them are useful. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Jan 12 01:52:28 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C935312955A for ; Thu, 12 Jan 2017 01:52:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 UquJgaHhMoeX for ; Thu, 12 Jan 2017 01:52:09 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83F8E12953E for ; Thu, 12 Jan 2017 01:52:09 -0800 (PST) Received: from [192.168.3.88] (142-135-17-190.fibertel.com.ar [190.17.135.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id C07B882C32; Thu, 12 Jan 2017 10:52:06 +0100 (CET) To: otroan@employees.org, Brian E Carpenter References: <89c6a9a4-e561-dee3-8899-17ae50ae4c2a@gmail.com> <44FCCC34-7995-4E10-85E9-58C08C371416@employees.org> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <0453eb8d-757a-38c5-6e7e-40bda416acba@si6networks.com> Date: Thu, 12 Jan 2017 06:51:36 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <44FCCC34-7995-4E10-85E9-58C08C371416@employees.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 09:52:11 -0000 Hi, Ole, On 01/12/2017 05:45 AM, otroan@employees.org wrote: >> This draft describes real issues but the information is a bit out >> of date. Can we ask the authors to confirm that things are still >> the same for current o/s releases? Then publish quickly so that we >> can start the *real* discussion: how to fix? > > This draft shouldn't be gating any real discussion. If there are > solutions please offer them now. Noting the problem, and providing datapoints is useful, IMO. > I have read through the draft again. While the draft has some points, > these are issues that has been discussed extensively. I struggle to > see how this will lead to and "fixes". > > I have a suggestion. Given that we have beaten on this particular > horse a lot over the last 15 years. Could we redo this draft into a > "Why?" draft in the style of RFC7421? Explain the issues, explain the > design choices and why the mechanisms function as they do, but don't > phrase it as a problem that needs to be fixed. The fact that you get different outcomes for different systems, setups, etc., does not seem nice to me. As to the why...I wonder if a "well, there's the slaac folks, and the dhcpv6 folks..." document would be "publishable".. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Jan 12 01:54:09 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 747E31294C8 for ; Thu, 12 Jan 2017 01:54:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 5fcJ8_ylA97h for ; Thu, 12 Jan 2017 01:54:07 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8DC0127058 for ; Thu, 12 Jan 2017 01:54:06 -0800 (PST) Received: from [192.168.3.88] (142-135-17-190.fibertel.com.ar [190.17.135.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id A282F82BA9; Thu, 12 Jan 2017 10:54:02 +0100 (CET) To: Mark Smith , joel jaeggli References: <67b3af77-3ab6-95f2-93c5-45d036efb935@bogus.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: Date: Thu, 12 Jan 2017 06:53:51 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-considerations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 09:54:08 -0000 Hi, Mark, On 01/12/2017 06:38 AM, Mark Smith wrote: > > > On 12 Jan. 2017 1:04 pm, "joel jaeggli" > wrote: > > For me personally, the presence of npt6 or indeed any form of ula only > deployment, save perhaps for ephemeral private networks is a bright > line not to be crossed. I find it hard to support a document that treats > the subject without recommending never to do those things. > > > I'm nearly in entire agreement with that. > > The specific use case I was referring to is an AMI smartgrid network > with the meters only having a ULA address. They never should be > reachable from the Internet, and only need to be reachable to/from their > management applications. Providing them with GUAs, even if protected by > a network firewall somewhere, creates the possibility of reachability > to/from the Internet, which is an unacceptable risk. > > Although hosts having and choosing between multiple addresses increases > complexity, I think the ability to create domains of different > reachability based on address types is a useful security feature. +1 Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Jan 12 01:58:30 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 021E112954D for ; Thu, 12 Jan 2017 01:58:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 9eH0Z6Dbpa_Y for ; Thu, 12 Jan 2017 01:58:27 -0800 (PST) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 022EB1293F8 for ; Thu, 12 Jan 2017 01:58:27 -0800 (PST) Received: by mail-vk0-x22e.google.com with SMTP id 137so9217262vkl.0 for ; Thu, 12 Jan 2017 01:58:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+fPa8fFb9IadigfYQ4O8K/ErHPB3f1SjDfzR9pUm7Ko=; b=bHOXBAdRWysoXu1j+0R4pul+48vyZf2ncRBgvzJs5X4bzAthKDEuMcRQIXym98Kd/H c9AMO3XoYazu1EiIxXeZDhbWzdNdrS/DBeBL/wRhf4s913KogLNKZIwXxDIGNXQe/EhC PwFCJG7S7+kFgss1hqYWSEXuuUTZqBECD+Gpj6PYSUBdVVQImwdeaXLlhYqew2g7Yeju UhmVYufWGlFVgGU7tBXbFP0DKv9qUWQhTNyA3Ulyl3EdfdxvJ/ot1iKCjT7WXpWIZ5gY ftrVvCh/5V+QKM6cqS+rhenjheHTCWE3AoypN08TiWmdRoO6vR5h4RFqp5UL9VhnDwTI Bmtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+fPa8fFb9IadigfYQ4O8K/ErHPB3f1SjDfzR9pUm7Ko=; b=ev4Dvn9MsFCQBkp1Nr5RhmUaaQ2AzW9gHnrylQ/7Iy3/5bKVnL/zF26YrsItNJpsSW 3c/If1a+2cbosqmG+Bd1vklr3eBcehtqBnc9RS9g5Nbp1+0QidhIar82CNAqzQoe5urV W0M8Bi3WZyEL5BcxP8cuR8aETe9UfANfi6iHrHNrkH60N7ebpaAh1ntSAEvN2JfCOEbm JjAKvUkT4YwjFdw5pUn3JsuhJ8NEIP2VJfs8pJkBb2qUht4oKlSHRXHWIoX6w7A4LzFp 8j9UCMK6zCKIOsdaoEBuB+ku/lvotYEVZoZ42iw7f7h+tw8nUCcUp0OTpXfIpzNxUO7p DSPA== X-Gm-Message-State: AIkVDXKPoQJlVsI7DrjNFUkhRbIgXJDVwk9REeDbH4fKLhSla+yBI0zb1yN+QFCXzl5inlI5pevO/qPifR81QQ== X-Received: by 10.31.238.6 with SMTP id m6mr5525179vkh.28.1484215106130; Thu, 12 Jan 2017 01:58:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.2.235 with HTTP; Thu, 12 Jan 2017 01:58:25 -0800 (PST) Received: by 10.176.2.235 with HTTP; Thu, 12 Jan 2017 01:58:25 -0800 (PST) In-Reply-To: References: <67b3af77-3ab6-95f2-93c5-45d036efb935@bogus.com> From: Mark Smith Date: Thu, 12 Jan 2017 20:58:25 +1100 Message-ID: To: Fernando Gont Content-Type: multipart/alternative; boundary=94eb2c1497142bd97f0545e2c2ca Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-considerations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 09:58:30 -0000 --94eb2c1497142bd97f0545e2c2ca Content-Type: text/plain; charset=UTF-8 On 12 Jan. 2017 8:54 pm, "Fernando Gont" wrote: Hi, Mark, On 01/12/2017 06:38 AM, Mark Smith wrote: > > > On 12 Jan. 2017 1:04 pm, "joel jaeggli" > wrote: > > For me personally, the presence of npt6 or indeed any form of ula only > deployment, save perhaps for ephemeral private networks is a bright > line not to be crossed. I find it hard to support a document that treats > the subject without recommending never to do those things. > > > I'm nearly in entire agreement with that. > > The specific use case I was referring to is an AMI smartgrid network > with the meters only having a ULA address. They never should be > reachable from the Internet, and only need to be reachable to/from their > management applications. Providing them with GUAs, even if protected by > a network firewall somewhere, creates the possibility of reachability > to/from the Internet, which is an unacceptable risk. > And just to make sure it's clear, it's not a hypothetical network. http://www.silverspringnet.com/article/uncategorized/ausnet-services-selects-silver-spring-networks-for-advanced-metering-roll-out/ > Although hosts having and choosing between multiple addresses increases > complexity, I think the ability to create domains of different > reachability based on address types is a useful security feature. +1 Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 --94eb2c1497142bd97f0545e2c2ca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 12 Jan. 2017 8:54 pm, "Fernando Gont" <fgont@si6networks.com> wrote:
Hi, Mark,

On 01/12/2017 06:38 AM, Mark Smith wrote:
>
>
> On 12 Jan. 2017 1:04 pm, "joel jaeggli" <joelja@bogus.com
> <mailto:joelja@bogus.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0For me personally, the presence of npt6 or indeed a= ny form of ula only
>=C2=A0 =C2=A0 =C2=A0deployment, save=C2=A0 perhaps for ephemeral privat= e networks is a bright
>=C2=A0 =C2=A0 =C2=A0line not to be crossed. I find it hard to support a= document that treats
>=C2=A0 =C2=A0 =C2=A0the subject without recommending never to do those = things.
>
>
> I'm nearly in entire agreement with that.
>
> The specific use case I was referring to is an AMI smartgrid network > with the meters only having a ULA address. They never should be
> reachable from the Internet, and only need to be reachable to/from the= ir
> management applications. Providing them with GUAs, even if protected b= y
> a network firewall somewhere, creates the possibility of reachability<= br> > to/from the Internet, which is an unacceptable risk.
>

And just to make sure it's clear, it's not a hypoth= etical network.

=

> Although hosts having and choosing between multiple addresses increase= s
> complexity, I think the ability to create domains of different
> reachability based on address types is a useful security feature.

+1

Cheers,
--
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com<= br> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





--94eb2c1497142bd97f0545e2c2ca-- From nobody Thu Jan 12 04:19:09 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40D8C1295C0 for ; Thu, 12 Jan 2017 04:19:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=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 udncxIkqHFEM for ; Thu, 12 Jan 2017 04:19:02 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id A1C351295C3 for ; Thu, 12 Jan 2017 04:18:59 -0800 (PST) Received: from stereo.hq.phicoh.net ([::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #127) id m1cReLJ-0000GHC; Thu, 12 Jan 2017 13:18:57 +0100 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bF054DD66@u-1.phicoh.com References: <1E7F90AC-79BB-49BE-B397-EC829EA95AA4@gmail.com> <7456833d-aa3f-d368-6041-cfdc1ac95f6f@si6networks.com> <89fc8838-f6cd-1647-8468-1c8c11466aff@si6networks.com> In-reply-to: Your message of "Thu, 12 Jan 2017 18:57:40 +0900 ." Date: Thu, 12 Jan 2017 13:18:56 +0100 Archived-At: Subject: Re: [v6ops] update to rfc2464bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 12:19:08 -0000 >> So far, the only two standardized algorithms for generating IIDs with >> SLAAC are RFC7217, RFC4941, and traditional slaac (modified eui-64). >> Clearly, you can hack your code and commit it. Being that this is >> standardization body, I would expect that we're agree on standardizing >> reasonable approaches, and calling bad approaches as such. >> > >Sure. If you can find rough consensus to say all other methods of >generating IIDs are bad and should not be used, the IETF will publish a >document saying that. My bet is that you won't. Personally I'd say "Modified EUI-64 SHOULD NOT be used on new installations. Modified EUI-64 SHOULD be implemented" I think modified EUI-64 with stable MAC addresses has lots of interesting use cases. And it is upto the admin to determine what is the right thing to do. From nobody Thu Jan 12 07:03:23 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DE6B129464 for ; Thu, 12 Jan 2017 07:03:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.111 X-Spam-Level: X-Spam-Status: No, score=-4.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=jisc365.onmicrosoft.com 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 mNqCLfVhuEo1 for ; Thu, 12 Jan 2017 07:03:14 -0800 (PST) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C8B012943C for ; Thu, 12 Jan 2017 07:03:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc365.onmicrosoft.com; s=selector1-jisc-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=TTb2kcLc1/LEST0wZ1yMqnCxUb4J9LtnruLbXmOfLQQ=; b=kV6eof0N+axwiMAevWfymxCdBD91/hRnEKA1BugOwHPfoUFOuEwOBGk0F+jcXA1mp9QEEIGI+HhGNMQTylK/XXullhpdp3sePeE5Qotcswfns68Nf9StUl3zXSQM3bPKGC7iXJYGQRefdb8WO3OgZyBvXLuyFSK14m+PsKj+9Vg= Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01lp0212.outbound.protection.outlook.com [213.199.154.212]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-53-oIr1NhdkON6iIltxuQgP7w-1; Thu, 12 Jan 2017 15:03:10 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1137.eurprd07.prod.outlook.com (10.163.188.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.845.3; Thu, 12 Jan 2017 15:03:09 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::5973:c4fc:6c1c:27c2]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::5973:c4fc:6c1c:27c2%14]) with mapi id 15.01.0845.014; Thu, 12 Jan 2017 15:03:08 +0000 From: Tim Chown To: Ron Bonica Thread-Topic: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem Thread-Index: AdJsHl8eSkgq9pmdSH+a6rrO1byUfgAxpysA Date: Thu, 12 Jan 2017 15:03:08 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3259) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [194.82.140.195] x-ms-office365-filtering-correlation-id: cce5f474-1a55-49db-3903-08d43afc1eca x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:AM3PR07MB1137; x-microsoft-exchange-diagnostics: 1; AM3PR07MB1137; 7:mBrwA0bTfM4OfyOlYY7PUkHZwDlEfHAkr9mygs+YNboMnzSyRB9WLLIom2LCoc14w+4xx+w80+IsiMHpWs22YVhe9yNnnjFPkByReYxBZwyQ1M8CfSxoE0i//G3g/8p54jiQB8A2MgDtVeLU0650IMRjqhxaJc3hasSQCIdwGIlnJOsm9Ws3gpync8+vnwEA8EipJhKbDryqy+lA7/AJvYqxRgUfYbvzU/8VlCpQfWsJFMEsxIJuWoaUKKMMRmNoJio0tFw3svPCMbGNI/whpwV0VMvkQN/HvSrYZ41zdWQ2IqaZjDi3wUcgXTS7rD2xx5DCICVs+u9jsKgbr7Zd0bR1LeGMopdqIAdrHkNxekluthMavSprAdzPV/iaRolRl6W7ZBzWVzBIOYyeZfw/DMIFE7zkFf7v9qEPqgZ8ZMlgxO1j5nVbwDG2cvCgD6CM8CogRLsxRvotK6UNw9EauQ==; 20:hU3JUcviQNrRY2aYMR7lnjpJsgzj5DGyzNYgtCGB/5A4wMR02zt8SMCnD69IciWIzNO2N1USfoXmJ205H7qCfSzjnS6dD7+5Io4dEE1P6CojXz3LAXkQJ5udJoeTTahQ9MMQqIu92jvRIq1YZs2ItE7mpn9bQKd7A3neLj9Z4TM= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123560025)(20161123562025)(20161123555025)(20161123564025)(6072148); SRVR:AM3PR07MB1137; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1137; x-forefront-prvs: 018577E36E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(199003)(189002)(24454002)(38730400001)(6486002)(36756003)(229853002)(99286003)(76176999)(6436002)(6506006)(8666007)(189998001)(97736004)(86362001)(101416001)(230783001)(42882006)(6916009)(2950100002)(5660300001)(6116002)(50986999)(102836003)(110136003)(3846002)(2900100001)(5250100002)(68736007)(57306001)(7736002)(305945005)(83716003)(3280700002)(92566002)(81156014)(81166006)(8676002)(6512007)(1941001)(82746002)(74482002)(8936002)(2906002)(4326007)(66066001)(105586002)(50226002)(106356001)(3660700001)(33656002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1137; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <696C0F8210B0A045BC2F0FE7DDE32AA4@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jan 2017 15:03:08.6949 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1137 X-MC-Unique: oIr1NhdkON6iIltxuQgP7w-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 15:03:22 -0000 SGksDQoNCj4gT24gMTEgSmFuIDIwMTcsIGF0IDE1OjM3LCBSb24gQm9uaWNhIDxyYm9uaWNhQGp1 bmlwZXIubmV0PiB3cm90ZToNCj4gDQo+IEZvbGtzLA0KPiANCj4gRHJhZnQtaWV0Zi12Nm9wcy1k aGNwdjYtc2xhYWMtcHJvYmxlbSB3YXMgaW50cm9kdWNlZCAzLjUgeWVhcnMgYWdvLCBidXQgaGFz IG1hZGUgbGl0dGxlIHByb2dyZXNzIGluIHRoZSBsYXN0IHllYXIuIFRoZXJlZm9yZSwgaXQgYmVj b21lIG5lY2Vzc2FyeSBmb3IgdGhlIGNoYWlycyB0byByZWV2YWx1YXRlIHdoZXRoZXIgdGhpcyBk cmFmdCBzaG91bGQgY29udGludWUgdG8gYmUgYSBXRyBpdGVtLg0KPiANCj4gSWYgeW91IGhhdmUg YW4gb3BpbmlvbiBvbiB0aGlzIHN1YmplY3QsIHBsZWFzZSBwb3N0IGl0IHRvIHRoZSBtYWlsaW5n IGxpc3QgYnkgMS8yNS8xNy4gT3B0aW9ucyBhcmU6DQo+IA0KPiAxKSBDb250aW51ZSB0byB3b3Jr IG9uIHRoZSBkcmFmdCB3aXRoIGFuIGV5ZSB0b3dhcmQgcHVibGljYXRpb24gaW4gMjAxNw0KPiAy KSBBbGxvdyB0aGUgZHJhZnQgdG8gZXhwaXJlDQoNCkl04oCZcyB0cmlja3kuDQoNCkkgZG8gZmlu ZCBteXNlbGYgcmVmZXJyaW5nIHBlb3BsZSB0byB0aGlzIGRvY3VtZW50IGFzIGEgcHJvYmxlbSBz dGF0ZW1lbnQsIGZyb20gdGltZSB0byB0aW1lLiAgSW4gdGhhdCBjb250ZXh0LCBpdOKAmXMgdXNl ZnVsLiANCg0KQnV0IGFzIE9sZSBzYXlzLCB3aGlsZSBhIG51bWJlciBvZiBhbWJpZ3VpdGllcyBh cmUgbm90ZWQsIHRoZXJlIGFyZSBubyDigJxmaXhlc+KAnSBwcm9wb3NlZC4gIA0KDQpJZiB0aGUg ZG9jdW1lbnQgaXMgdG8gYmUgcHVibGlzaGVkLCBzaG91bGQgd2Ugbm90IG1ha2Ugc29tZSByZWNv bW1lbmRhdGlvbnM/DQoNCklmIHRoZSBBcHBlbmRpeCBpcyB0byByZW1haW4sIHJlc3VsdHMgZm9y IGN1cnJlbnQgT1NlcyB3b3VsZCBiZSB1c2VmdWwuDQoNClRpbQ0KDQo= From nobody Thu Jan 12 07:17:26 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05AF5129855 for ; Thu, 12 Jan 2017 07:17:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.111 X-Spam-Level: X-Spam-Status: No, score=-4.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=jisc365.onmicrosoft.com 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 z9_zxVECjBzo for ; Thu, 12 Jan 2017 07:17:22 -0800 (PST) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 816B81297EB for ; Thu, 12 Jan 2017 07:17:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc365.onmicrosoft.com; s=selector1-jisc-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+PwoZiZGZpF50Ql9M1SvrsZcotPCJP8mThguXrOovmU=; b=J9Qa6N2Wln5OyVvvaHkMo8+KRnZsp7vsgRfmA7+PA3NDTL1OCjzxQCQroKgAHJ85yArVuuKeGJtkGEQXS9gO5nyF1kHZsk7j84sw++Zs5TQupAq1KWZFrW9HmBqsbPKX80tb2N/fPSwrgNaDp8yvAPNzIMnXRz08GuB1/GYe3Ps= Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-ve1eur03lp0150.outbound.protection.outlook.com [213.199.154.150]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-49-Uv6o9FojPoutY9CgufKuow-1; Thu, 12 Jan 2017 15:17:18 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1137.eurprd07.prod.outlook.com (10.163.188.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.845.3; Thu, 12 Jan 2017 15:17:17 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::5973:c4fc:6c1c:27c2]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::5973:c4fc:6c1c:27c2%14]) with mapi id 15.01.0845.014; Thu, 12 Jan 2017 15:17:16 +0000 From: Tim Chown To: Brian E Carpenter Thread-Topic: [v6ops] draft-ietf-v6ops-ula-usage-considerations Thread-Index: AdJsIL/eGNHYeD7QSh6qBQxZ+ciwNwAV2BgAAAGv1gAAGgVqAA== Date: Thu, 12 Jan 2017 15:17:16 +0000 Message-ID: References: <67b3af77-3ab6-95f2-93c5-45d036efb935@bogus.com> <048a00cd-ff4f-abd8-cc15-36df70964748@gmail.com> In-Reply-To: <048a00cd-ff4f-abd8-cc15-36df70964748@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3259) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [194.82.140.195] x-ms-office365-filtering-correlation-id: e8dbb024-1312-4792-a88d-08d43afe183c x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:AM3PR07MB1137; x-microsoft-exchange-diagnostics: 1; AM3PR07MB1137; 7:MMKGizrvsPcDqqHCb5lXsItnpbY06VpwDoAHJ9CQn+rQOAd/x6jKGjOKl+huWuEdqSBgzvjl5IStLRB85MWkEBQPniQm4K8FrE5bNviP+gGOK1stpQMZbcUB2Mm+gFJeFb8k881B8HjxvuQI3WhjTZ4lHezwbJ5phmpCjrlwyEhAwRd64/J4YkAURfffv0WzzVun7qJuiZ2LXL35YKCExXKlFncwLpNUFc45SB33agDxWD9cfUEDgxunTP7uxClvRTcKSmKgs5icrXNvvi4vgaf1xYtGs8eOaPYLUihMvn73ZdtjBxoegr8LTwDtz4lcAmlEPxqNQjhWpXzWGBZTMLG+xWu8TOXIqbpLPADGSzCmsRum+yabHsPE9woW5xe5oPh3IHS8uI7d6ZW/6agxbGtp9e03UXQ5QobfDdEwTC8olIVpzf+M3ZWEcAw/LIkMqHgfoToHbEe8QaXBwd5hvg==; 20:INjOl9F9R2Nq3RxHx+SHdZ2o1Uqyn2y/dgduHcYIY4ew8E4cyhzQ6IO2Om6lcFwmKkF0M5U0bDDcJLCaIHaIU6riLiFR+jU3fQtbQcXt2flcAs3x2eO1bZ1rga3Ihdr2016BBVAPQ0bSmCbxH+PrgQpo2sVWcEm4oRI2qFXsea8= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123560025)(20161123562025)(20161123555025)(20161123564025)(6072148); SRVR:AM3PR07MB1137; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1137; x-forefront-prvs: 018577E36E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(189002)(24454002)(199003)(377454003)(8676002)(81156014)(81166006)(92566002)(6512007)(305945005)(83716003)(7736002)(3280700002)(106356001)(105586002)(50226002)(33656002)(3660700001)(6306002)(82746002)(66066001)(74482002)(8936002)(4326007)(2906002)(189998001)(97736004)(6506006)(39060400001)(230783001)(86362001)(101416001)(38730400001)(6486002)(229853002)(36756003)(6436002)(76176999)(99286003)(5250100002)(68736007)(57306001)(42882006)(6916009)(2950100002)(110136003)(102836003)(3846002)(2900100001)(6116002)(50986999)(5660300001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1137; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <54C16D8DF8194A4D864C35A5528F2F3D@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jan 2017 15:17:16.7774 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1137 X-MC-Unique: Uv6o9FojPoutY9CgufKuow-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-considerations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 15:17:25 -0000 PiBPbiAxMiBKYW4gMjAxNywgYXQgMDI6NTIsIEJyaWFuIEUgQ2FycGVudGVyIDxicmlhbi5lLmNh cnBlbnRlckBnbWFpbC5jb20+IHdyb3RlOg0KPiANCj4gT24gMTIvMDEvMjAxNyAxNTowMywgam9l bCBqYWVnZ2xpIHdyb3RlOg0KPj4gRm9yIG1lIHBlcnNvbmFsbHksIHRoZSBwcmVzZW5jZSBvZiBu cHQ2IG9yIGluZGVlZCBhbnkgZm9ybSBvZiB1bGEgb25seQ0KPj4gZGVwbG95bWVudCwgc2F2ZSAg cGVyaGFwcyBmb3IgZXBoZW1lcmFsIHByaXZhdGUgbmV0d29ya3MgaXMgYSBicmlnaHQNCj4+IGxp bmUgbm90IHRvIGJlIGNyb3NzZWQuIEkgZmluZCBpdCBoYXJkIHRvIHN1cHBvcnQgYSBkb2N1bWVu dCB0aGF0IHRyZWF0cw0KPj4gdGhlIHN1YmplY3Qgd2l0aG91dCByZWNvbW1lbmRpbmcgbmV2ZXIg dG8gZG8gdGhvc2UgdGhpbmdzLg0KPiANCj4gSSBhZ3JlZSB3aXRoIHRoYXQgYW5kIHdpdGggVmlj dG9yJ3MgY29tbWVudC4gQnV0IGRvIHlvdSB0aGluayB3ZSBjb3VsZA0KPiBlbGV2YXRlIHRoaXMg dG8gQkNQPyBJJ20gbm90IGNvbWZvcnRhYmxlIHRoYXQgd2UgaGF2ZSBlbm91Z2ggZXhwZXJpZW5j ZQ0KPiB0byBkbyB0aGF0Lg0KDQpJIGFncmVlIHdpdGggSm9lbCwgQnJpYW4sIExvcmVuem8gYW5k IFZpY3RvcuKAmXMgY29tbWVudHMuICANCg0KSSB0aGluayB3b3JrIHNob3VsZCBjb250aW51ZSBv biB0aGUgZG9jdW1lbnQsIGJ1dCBhcyBCcmlhbiBzdWdnZXN0cyBCQ1AgaXMgbGlrZWx5IHByZW1h dHVyZTsgSW5mb3JtYXRpb25hbCBpcyBtb3JlIGFwcHJvcHJpYXRlLCBpZiB3ZSBjYW4gY29uZGVu c2UgdGhlIHRleHQgdG93YXJkcyBjb25zZW5zdXMuIA0KDQpUaGUgY2hhbGxlbmdlIGlzIGZpbmRp bmcgdGhlIG1pbmltdW0gc2V0IG9mIG1lc3NhZ2VzIHRvIGluY2x1ZGUgaW4gdGhlIGRvY3VtZW50 IHRvIGFjaGlldmUgdGhhdCBjb25zZW5zdXMgdG8gcHVibGlzaC4gIEZvciBleGFtcGxlLCBJ4oCZ bSBub3QgY29tZm9ydGFibGUgd2l0aCBTZWN0aW9uIDQuMi4xIG9uIE5QVHY2LiBCdXQgZGlmZmVy ZW50aWF0aW5nIFVMQS1vbmx5IGZyb20gVUxBK0dVQSBpcyBpbXBvcnRhbnQsIGFzIGlzIGVtcGhh c2lzaW5nIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gSVB2NiBVTEEgYW5kIElQdjQgUkZDMTkxOCBh c3N1bXB0aW9ucy4NCg0KVGltDQoNCj4+IA0KPj4gam9lbA0KPj4gDQo+PiBPbiAxLzExLzE3IDc6 MzkgQU0sIFJvbiBCb25pY2Egd3JvdGU6DQo+Pj4gRm9sa3MsDQo+Pj4gDQo+Pj4gRCByYWZ0LWll dGYtdjZvcHMtdWxhLXVzYWdlLWNvbnNpZGVyYXRpb25zIHdhcyBpbnRyb2R1Y2VkIDMuNSB5ZWFy cyBhZ28sIGJ1dCBoYXMgbWFkZSBsaXR0bGUgcHJvZ3Jlc3MgaW4gdGhlIGxhc3QgeWVhci4gVGhl cmVmb3JlLCBpdCBiZWNvbWUgbmVjZXNzYXJ5IGZvciB0aGUgY2hhaXJzIHRvIHJlZXZhbHVhdGUg d2hldGhlciB0aGlzIGRyYWZ0IHNob3VsZCBjb250aW51ZSB0byBiZSBhIFdHIGl0ZW0uDQo+Pj4g DQo+Pj4gSWYgeW91IGhhdmUgYW4gb3BpbmlvbiBvbiB0aGlzIHN1YmplY3QsIHBsZWFzZSBwb3N0 IGl0IHRvIHRoZSBtYWlsaW5nIGxpc3QgYnkgMS8yNS8xNy4gT3B0aW9ucyBhcmU6DQo+Pj4gDQo+ Pj4gMSkgQ29udGludWUgdG8gd29yayBvbiB0aGUgZHJhZnQgd2l0aCBhbiBleWUgdG93YXJkIHB1 YmxpY2F0aW9uIGluIDIwMTcNCj4+PiAyKSBBbGxvdyB0aGUgZHJhZnQgdG8gZXhwaXJlDQo+Pj4g DQo+Pj4gU2lsZW5jZSBvciBsaW1pdGVkIHJlc3BvbnNlIHdpbGwgYmUgaW50ZXJwcmV0ZWQgYXMg YSBsYWNrIG9mIGludGVyZXN0IGluIHRoZSBkcmFmdC4NCj4+PiANCj4+PiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUm9uLCBMZWUgYW5kIEZyZWQNCj4+PiANCj4+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IHY2 b3BzIG1haWxpbmcgbGlzdA0KPj4+IHY2b3BzQGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KPj4+IA0KPj4gDQo+PiANCj4+IA0KPj4gDQo+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gdjZv cHMgbWFpbGluZyBsaXN0DQo+PiB2Nm9wc0BpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KPj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4gdjZv cHNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9w cw0KPiANCg0K From nobody Thu Jan 12 07:52:52 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D631412940E for ; Thu, 12 Jan 2017 07:52:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.721 X-Spam-Level: X-Spam-Status: No, score=-17.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 r4LzqqkqqXkS for ; Thu, 12 Jan 2017 07:52:48 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ED681293FB for ; Thu, 12 Jan 2017 07:52:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2952; q=dns/txt; s=iport; t=1484236367; x=1485445967; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=lg1ktykzEHtZnW2ouPqlECFbparjlxtPCvQGu+sPNJU=; b=g1pptADxjZNJYQev7Bg//XRKL64KwHKmqkz2lJq2mr2acSdCBtxCmOLE H3TcRcqVBlSNmYZx/YplZosl3w80/MpkUul9VZIzJGwo8QepOu6BHMPIC s8dC4lDgNQMxsmI/M0bSydC3/N1qA7eZQnV3+XsB99HtUO7MCk/tmtsEJ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AbAQCtpXdY/49dJa1dDgsBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM8AQEBAQEfX4EJB4NJigiSFZUqgg0fC4V4AhqBZz8UAQIBAQE?= =?us-ascii?q?BAQEBYyiEaQEBAQMBAQEhEToLEAIBCBgCAiYCAgIlCxUQAQEEAQ0FiHgIDrA9g?= =?us-ascii?q?iWKFAEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgQuHPIFZgQaHTC2CMQWbLAGGWop?= =?us-ascii?q?7gXeFDolliBOKUAEfOIFEFToQAYVjO3OHWYENAQEB?= X-IronPort-AV: E=Sophos;i="5.33,219,1477958400"; d="scan'208";a="193898094" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Jan 2017 15:52:46 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v0CFqkbv011236 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 12 Jan 2017 15:52:46 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 12 Jan 2017 09:52:45 -0600 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1210.000; Thu, 12 Jan 2017 09:52:45 -0600 From: "Bernie Volz (volz)" To: Tim Chown , Ron Bonica Thread-Topic: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem Thread-Index: AdJsHl8eSkgq9pmdSH+a6rrO1byUfgAxpysAAAPUDYA= Date: Thu, 12 Jan 2017 15:52:45 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1d.0.161209 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.131.32.247] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 15:52:50 -0000 SGk6DQoNCkkgYWxzbyB3b25kZXIgaWYgdGhlcmUgd2VyZSBzb21lIHByb3Bvc2VkIOKAnGZpeGVz 4oCdLCBwZXJoYXBzIHRoZXkgY291bGQgYmUgd29ya2VkIGludG8gdGhlIDMzMTViaXMgKGFzIHRo ZXkgcmVsYXRlIHRvIERIQ1B2NikuIEV2ZW4gaWYgd2UgZGlkbuKAmXQgaGl0IGV2ZXJ5dGhpbmcs IGltcHJvdmluZyB0aGluZ3MgYSBiaXQgaXMgYmV0dGVyIHRoYW4gbm90IGF0IGFsbD8gQnV0IHRo aXMgYWxzbyBtaWdodCBub3QgYmUgdGhlIGJlc3QgYXZlbnVlIGF0IHRoaXMgdGltZSwgZ2l2ZW4g d2hlcmUgd2UgYXJlIHdpdGggdGhlIDMzMTViaXMgd29yay4gQW5kLCBJIGNlcnRhaW5seSBkb27i gJl0IHdhbnQgdG8gc3RhcnQgYSBsb25nIGRlYmF0ZSBvbiB0aGUgTSZPIGJpdHMuDQoNClBlcmhh cHMgaWYgdGhlIGF1dGhvcnMgaGF2ZSBhIGxpc3Qgb2YgYSBmZXcgcmVjb21tZW5kYXRpb25zIGZv ciB3aGF0IHdlIG1pZ2h0IGluY29ycG9yYXRlIGluIHRoZSAzMzE1YmlzIGRvY3VtZW50LCB3ZSAo Y29hdXRob3JzIGFuZCBESEMgV0cpIGNvdWxkIHJldmlldyB0aGVzZSBhbmQgaWYgdGhlcmUgaXMg c3VmZmljaWVudCBjb25zZW5zdXMgdXBkYXRlIHRoZSBkb2N1bWVudCBhY2NvcmRpbmdseT8NCg0K U2VlIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWRoYy1yZmMzMzE1Ymlz LTA2LiAoVGhlIGNvYXV0aG9ycyBhcmUgc3RpbGwgd29ya2luZyB0aHJvdWdoIG91ciBiYWNrbG9n IG9mIGFib3V0IDMwMCBjb21tZW50cyBkdXJpbmcgV0dMQyDigJMgd2UgaGF2ZSBkb25lIGFib3V0 IDc1JSBvZiB0aGVtLikNCg0KLSBCZXJuaWUNCg0KT24gMS8xMi8xNywgMTA6MDMgQU0sICJ2Nm9w cyBvbiBiZWhhbGYgb2YgVGltIENob3duIiA8djZvcHMtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhh bGYgb2YgVGltLkNob3duQGppc2MuYWMudWs+IHdyb3RlOg0KDQogICAgSGksDQogICAgDQogICAg PiBPbiAxMSBKYW4gMjAxNywgYXQgMTU6MzcsIFJvbiBCb25pY2EgPHJib25pY2FAanVuaXBlci5u ZXQ+IHdyb3RlOg0KICAgID4gDQogICAgPiBGb2xrcywNCiAgICA+IA0KICAgID4gRHJhZnQtaWV0 Zi12Nm9wcy1kaGNwdjYtc2xhYWMtcHJvYmxlbSB3YXMgaW50cm9kdWNlZCAzLjUgeWVhcnMgYWdv LCBidXQgaGFzIG1hZGUgbGl0dGxlIHByb2dyZXNzIGluIHRoZSBsYXN0IHllYXIuIFRoZXJlZm9y ZSwgaXQgYmVjb21lIG5lY2Vzc2FyeSBmb3IgdGhlIGNoYWlycyB0byByZWV2YWx1YXRlIHdoZXRo ZXIgdGhpcyBkcmFmdCBzaG91bGQgY29udGludWUgdG8gYmUgYSBXRyBpdGVtLg0KICAgID4gDQog ICAgPiBJZiB5b3UgaGF2ZSBhbiBvcGluaW9uIG9uIHRoaXMgc3ViamVjdCwgcGxlYXNlIHBvc3Qg aXQgdG8gdGhlIG1haWxpbmcgbGlzdCBieSAxLzI1LzE3LiBPcHRpb25zIGFyZToNCiAgICA+IA0K ICAgID4gMSkgQ29udGludWUgdG8gd29yayBvbiB0aGUgZHJhZnQgd2l0aCBhbiBleWUgdG93YXJk IHB1YmxpY2F0aW9uIGluIDIwMTcNCiAgICA+IDIpIEFsbG93IHRoZSBkcmFmdCB0byBleHBpcmUN CiAgICANCiAgICBJdOKAmXMgdHJpY2t5Lg0KICAgIA0KICAgIEkgZG8gZmluZCBteXNlbGYgcmVm ZXJyaW5nIHBlb3BsZSB0byB0aGlzIGRvY3VtZW50IGFzIGEgcHJvYmxlbSBzdGF0ZW1lbnQsIGZy b20gdGltZSB0byB0aW1lLiAgSW4gdGhhdCBjb250ZXh0LCBpdOKAmXMgdXNlZnVsLiANCiAgICAN CiAgICBCdXQgYXMgT2xlIHNheXMsIHdoaWxlIGEgbnVtYmVyIG9mIGFtYmlndWl0aWVzIGFyZSBu b3RlZCwgdGhlcmUgYXJlIG5vIOKAnGZpeGVz4oCdIHByb3Bvc2VkLiAgDQogICAgDQogICAgSWYg dGhlIGRvY3VtZW50IGlzIHRvIGJlIHB1Ymxpc2hlZCwgc2hvdWxkIHdlIG5vdCBtYWtlIHNvbWUg cmVjb21tZW5kYXRpb25zPw0KICAgIA0KICAgIElmIHRoZSBBcHBlbmRpeCBpcyB0byByZW1haW4s IHJlc3VsdHMgZm9yIGN1cnJlbnQgT1NlcyB3b3VsZCBiZSB1c2VmdWwuDQogICAgDQogICAgVGlt DQogICAgDQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCiAgICB2Nm9wcyBtYWlsaW5nIGxpc3QNCiAgICB2Nm9wc0BpZXRmLm9yZw0KICAgIGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCiAgICANCg0K From nobody Thu Jan 12 07:59:58 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FDBC127735 for ; Thu, 12 Jan 2017 07:59:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jvknet-com.20150623.gappssmtp.com 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 xjU7m2qeOkmy for ; Thu, 12 Jan 2017 07:59:55 -0800 (PST) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 961BB129400 for ; Thu, 12 Jan 2017 07:59:54 -0800 (PST) Received: by mail-vk0-x22f.google.com with SMTP id r136so15241146vke.1 for ; Thu, 12 Jan 2017 07:59:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jvknet-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=FNr0vpRqbMaX5YK+JpC3CLxtaxxCU9kT7mOe7xBZDlQ=; b=Dn6FPcMKMZKx4Wm3Rg13i/bsHF5mIF7YOFDHYmNYFKaYPjULBXSL/Ue412m+mICDCt VjErgkFQTfeWid4AgtFRo+HhCD0M1LPaPHP8c+FOtFUmXnjJQJ2dsxjg7Zhc6zxWKZgk 29Is+0+o1o5l1n/9Ctrbi6yRhIJgmmEJCwVplPkomSW0ajgbDhlhXdvd9eWCndDWs87l pjPa7v7Ubb0VQQJD+M2SNKWPCNw90ltIe89voRHczuuN2tEyBL22Zbdq9664UDiuTAfc BknbrRK77splKhBLqGwnL2bW0GjtQbBfAXoOPgIuBvBLpy+R9pTqgCIkf1vkcIk61D8a YmQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=FNr0vpRqbMaX5YK+JpC3CLxtaxxCU9kT7mOe7xBZDlQ=; b=rdDemPxGnjsnTEqY7uTo2xwZjtWdD7p4K0IOK5aoiYz55x9S0rP+RruCg4xun15D9o +xr+7ws6HaOxr3UnvNsiY1UXvj8XbAz03Gckcf7xUj/qPT4QfsIRdhN7t/yLPmrwIZZJ CTcU701480n+C4hhifxG8sL5AEPiN6Umns40PZ16KxYsE5OpVjBd7dfs7q2Nho30iUFi R6kLmK7kp4xHHV1XkGt4GZWvU/j+SLZXw/vISFCbNm6qD4jQw3d04UndEw0M9N6Twv2d tY9DeSMCmSRXcVjdsQGnzHF+AU3rRBBc7EwiD7mpBUTX/+jNG6zTyH5ZTrO/+Zh3GNlx pagA== X-Gm-Message-State: AIkVDXI65UHKvANV4PdoYGxv7aw8dehvuiPgjnCmCawYSH7V8U0NGog7VAmWklagoDcHLBBVPID2RLk39manOA== X-Received: by 10.31.212.2 with SMTP id l2mr6081522vkg.134.1484236793624; Thu, 12 Jan 2017 07:59:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.235.195 with HTTP; Thu, 12 Jan 2017 07:59:53 -0800 (PST) In-Reply-To: References: <67b3af77-3ab6-95f2-93c5-45d036efb935@bogus.com> <048a00cd-ff4f-abd8-cc15-36df70964748@gmail.com> From: Victor Kuarsingh Date: Thu, 12 Jan 2017 10:59:53 -0500 Message-ID: To: Tim Chown Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-considerations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 15:59:57 -0000 Tim/all, As a way to condense the document and attempt to consolidate the information. Would concentrating on the following three models (listed below) be worth considering? We can also keep what is currently section 5 (general considerations) as well. (1). Isolated Networks. Brief: potential valid use. Not intended for (or specifically denied) Internet connectivity. We have a couple of solid use cases here, list key considerations (2). Multi-homed / Multi-addressed (i.e. ULA+GUA). Brief: potential valid use, other ways to solve problem ( On Thu, Jan 12, 2017 at 10:17 AM, Tim Chown wrote: >> On 12 Jan 2017, at 02:52, Brian E Carpenter wrote: >> >> On 12/01/2017 15:03, joel jaeggli wrote: >>> For me personally, the presence of npt6 or indeed any form of ula only >>> deployment, save perhaps for ephemeral private networks is a bright >>> line not to be crossed. I find it hard to support a document that treat= s >>> the subject without recommending never to do those things. >> >> I agree with that and with Victor's comment. But do you think we could >> elevate this to BCP? I'm not comfortable that we have enough experience >> to do that. > > I agree with Joel, Brian, Lorenzo and Victor=E2=80=99s comments. > > I think work should continue on the document, but as Brian suggests BCP i= s likely premature; Informational is more appropriate, if we can condense t= he text towards consensus. > > The challenge is finding the minimum set of messages to include in the do= cument to achieve that consensus to publish. For example, I=E2=80=99m not = comfortable with Section 4.2.1 on NPTv6. But differentiating ULA-only from = ULA+GUA is important, as is emphasising the difference between IPv6 ULA and= IPv4 RFC1918 assumptions. > > Tim > >>> >>> joel >>> >>> On 1/11/17 7:39 AM, Ron Bonica wrote: >>>> Folks, >>>> >>>> D raft-ietf-v6ops-ula-usage-considerations was introduced 3.5 years ag= o, but has made little progress in the last year. Therefore, it become nece= ssary for the chairs to reevaluate whether this draft should continue to be= a WG item. >>>> >>>> If you have an opinion on this subject, please post it to the mailing = list by 1/25/17. Options are: >>>> >>>> 1) Continue to work on the draft with an eye toward publication in 201= 7 >>>> 2) Allow the draft to expire >>>> >>>> Silence or limited response will be interpreted as a lack of interest = in the draft. >>>> >>>> Ron, Lee and Fred >>>> >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>>> >>> >>> >>> >>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Jan 12 08:01:52 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAB62129486 for ; Thu, 12 Jan 2017 08:01:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jvknet-com.20150623.gappssmtp.com 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 r5fdTC9hRbRX for ; Thu, 12 Jan 2017 08:01:44 -0800 (PST) Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D01212940D for ; Thu, 12 Jan 2017 08:01:44 -0800 (PST) Received: by mail-ua0-x234.google.com with SMTP id i68so17324598uad.0 for ; Thu, 12 Jan 2017 08:01:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jvknet-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=YUik00zYezafC63NzsDaU94FE1kcUZ+C5kURoiMJjs0=; b=eaLujAc5TVo2pPZQJIips/0DFVGHl32h4nNEF0ROkTS1r2SNytLsNgqVL2m527go2I 7qlSuP6qvqfPcZDsIGjFVtgZeHM4EBgGhF0z0COQoUuhQfTNPDODIzzajCtOSx5YyGhH ORhrOK779hvKoeiNRLQljIbuK65IrwYcgmJj7Ym5/08RGP/ZHU0AMDeg6NTchsnOXOxW chO4uKOh3XkQfMndd2sPwyeflYSD4Iq/TQLBRvlWnmmqwjQBZ/POyuyy0sQJKAhCbOSN z/1Oorn9bDxzDdeexgY6jpAc2y4dJWngVM7mq8yRAx3GSpWocrDl5XaN03cNdcRz62uY 1avw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=YUik00zYezafC63NzsDaU94FE1kcUZ+C5kURoiMJjs0=; b=QQTlNTuA8VPWxwiwPayxAS2k4X5RiUM/Uhm5hQY0vrrVl+3BtMuFAJuc7ooViWo3xe xhJfr6fi2yy/z77J31NNuXL+coFF+k4h689lH4ZziIQQCW8We+1hwTVAcBa5simNDbT4 TwGEKgzEeE7lvXSK0B7/9stutkluTXwA7HS4OYUkDP/5h/CcQp6lOozFvcfO0srSxbYv rPdDsSNLESXIK2Z46dz7vbk96sdrC3upzTi2Q8ahB3AEgXzSQUUKideArImhK36+cOEg lZPRzrLhwbQYAo6x5fYnjFK2RPVUf3O7CJJg5HRF/KZl5Voq3VmgPu9lIAT/A+A6xbhA 89qg== X-Gm-Message-State: AIkVDXIS6uLrhX2v2MczIP7K5eZRkeem40yxrLfEk5NHya6JTSJWW/KJlnX7gbUlncNrVpTTpKd/NLxch+8XLQ== X-Received: by 10.159.38.76 with SMTP id 70mr6548721uag.26.1484236903686; Thu, 12 Jan 2017 08:01:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.235.195 with HTTP; Thu, 12 Jan 2017 08:01:42 -0800 (PST) In-Reply-To: References: <67b3af77-3ab6-95f2-93c5-45d036efb935@bogus.com> <048a00cd-ff4f-abd8-cc15-36df70964748@gmail.com> From: Victor Kuarsingh Date: Thu, 12 Jan 2017 11:01:42 -0500 Message-ID: To: Tim Chown Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-considerations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 16:01:47 -0000 Sorry, pulled trigger too fast on last email. As a way to condense the document and attempt to consolidate the information. Would concentrating on the following three models (listed below) be worth considering? We can also keep what is currently section 5 (general considerations) as well. (1). Isolated Networks. Brief: potential valid use. Not intended for (or specifically denied) Internet connectivity. We have a couple of solid use cases here, list key considerations (2). Multi-homed / Multi-addressed (i.e. ULA+GUA). Brief: potential valid use, other ways to solve problem (3) Internet connected. Not valid choice, harmful, limiting, avoid. regards, Victor K > > On Thu, Jan 12, 2017 at 10:17 AM, Tim Chown wrote: >>> On 12 Jan 2017, at 02:52, Brian E Carpenter wrote: >>> >>> On 12/01/2017 15:03, joel jaeggli wrote: >>>> For me personally, the presence of npt6 or indeed any form of ula only >>>> deployment, save perhaps for ephemeral private networks is a bright >>>> line not to be crossed. I find it hard to support a document that trea= ts >>>> the subject without recommending never to do those things. >>> >>> I agree with that and with Victor's comment. But do you think we could >>> elevate this to BCP? I'm not comfortable that we have enough experience >>> to do that. >> >> I agree with Joel, Brian, Lorenzo and Victor=E2=80=99s comments. >> >> I think work should continue on the document, but as Brian suggests BCP = is likely premature; Informational is more appropriate, if we can condense = the text towards consensus. >> >> The challenge is finding the minimum set of messages to include in the d= ocument to achieve that consensus to publish. For example, I=E2=80=99m not= comfortable with Section 4.2.1 on NPTv6. But differentiating ULA-only from= ULA+GUA is important, as is emphasising the difference between IPv6 ULA an= d IPv4 RFC1918 assumptions. >> >> Tim >> >>>> >>>> joel >>>> >>>> On 1/11/17 7:39 AM, Ron Bonica wrote: >>>>> Folks, >>>>> >>>>> D raft-ietf-v6ops-ula-usage-considerations was introduced 3.5 years a= go, but has made little progress in the last year. Therefore, it become nec= essary for the chairs to reevaluate whether this draft should continue to b= e a WG item. >>>>> >>>>> If you have an opinion on this subject, please post it to the mailing= list by 1/25/17. Options are: >>>>> >>>>> 1) Continue to work on the draft with an eye toward publication in 20= 17 >>>>> 2) Allow the draft to expire >>>>> >>>>> Silence or limited response will be interpreted as a lack of interest= in the draft. >>>>> >>>>> Ron, Lee and Fred >>>>> >>>>> _______________________________________________ >>>>> v6ops mailing list >>>>> v6ops@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>>> >>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Jan 12 08:34:23 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D64C0129481 for ; Thu, 12 Jan 2017 08:34:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 mdfb9zIFjenJ for ; Thu, 12 Jan 2017 08:34:19 -0800 (PST) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED8E9128E19 for ; Thu, 12 Jan 2017 08:34:18 -0800 (PST) Received: by mail-oi0-x22b.google.com with SMTP id w204so29052217oiw.0 for ; Thu, 12 Jan 2017 08:34:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0JzcMbz3G/knsZoVt+KHXrwUqYQHBrBsKtekGCmnCZ8=; b=qSXtvZURF2fkOcey8btQKsoON69gneJhJDqrArl7oDf2qSZ58FW0kFCZlyjNVxkBjB W4XsW6u3ByNvRVtzNqm2rHY0Vw1Fvrm4kftAXDzBZqvorEzYS90fbxE5kPepKGxGm/p/ nJwn1emp+R3EECc1jLgcfSQH1wAqlCuvDuA2+3Mx+wC4LsdsAkPLDtDEXQO3P975aP9j PPk0cvaclVcVmAC/ufODuV8hk8s4xeZCWf1t8l2U6JSKENT4zStFiHUbKZjkHX3gs5iG oCABqBZ7WqdHVb/Na9p3ovT3iUbxTBgE9SMh8SJFwZAT15oT/t9uZCXGx8/OvyeI8+py 5XsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0JzcMbz3G/knsZoVt+KHXrwUqYQHBrBsKtekGCmnCZ8=; b=PAkevhmsyq6wWyO3m/E/9Q5vwUmJY6NT+QHhCofKJ7E3SuBFGHqNAHYggjRbdzA3JM INOXdvK2HlsD+oUoJFydsH2/RTitnfTS0BeIawO9iQ89UUaBSKB2LVi5YDT/pxoiVD2F Gyi6j1NKF1nPodFrNZeQ1pKW1GPCOHK+s+Y41Ine4fF14RqC9hGzXJ1j7yrmVoxYaHc9 sv7A/CXIgFPP66YS8xPraQYKAOH9KGu4IeNGhJuqwx/C20WQO1ruN8S7qJCqg5LU4yeP OT6k0nTL+qBXmulhgTugh+FqVOp1rhtKorjPolUQEEiY8BxiTVH1pBt1Ep1QPNEL6a4E SebA== X-Gm-Message-State: AIkVDXKHQ7mK8OOc4a9jX9aOYOlbbd5DYxZ778t6/wrwRS7PMv+7kOzHzy7jItXnBcDvjxuSpyka0zptOFPOcA== X-Received: by 10.202.213.17 with SMTP id m17mr7684793oig.104.1484238858292; Thu, 12 Jan 2017 08:34:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.227.102 with HTTP; Thu, 12 Jan 2017 08:34:17 -0800 (PST) In-Reply-To: References: From: Hemant Singh Date: Thu, 12 Jan 2017 11:34:17 -0500 Message-ID: To: Joe Touch Content-Type: multipart/alternative; boundary=001a113b0a38e9114a0545e84960 Archived-At: Cc: v6ops list Subject: Re: [v6ops] TCP related attacks/RFC3128 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 16:34:22 -0000 --001a113b0a38e9114a0545e84960 Content-Type: text/plain; charset=UTF-8 Joe, Thanks much for your reply and also thanks to Brian. Sure, even I surmised Fragment A and B as 1 and 2 but I thought an RFC editor should have caught this minor issue. Having seen Brian's reply related to individual submission, I see the edition issue. I forgot to mention another issue with RFC3128 in section 2.1. Fragment 2 says target is telnet (port 23) but then uses FTP in the sentence. FTP should be "telnet". Sure, I will file an Errata. Thanks for the clarification on the number of 8 octet units. Indeed, the total length in the IP header is 2 bytes and thus the maximum packet is 65536 but 13 bits only support 8192 bytes. I found that a cable modem is using 1480 in the fragment offset instead of 185. We should check what do router vendors do. On a different note, see that RFC3128 references RFC1858 which lists the minimum size of an IPv4 datagram as 68 bytes. Such small packets are used to attack ACLs on firewalls for TCP packets using an IP header which is 60 bytes in length. Wonder what the minimum size of an IPv6 packet is specified in any IPv6 RFC? I checked the IPv6 Node requirements RFC and don't find any minimum. Thanks, Hemant On Wed, Jan 11, 2017 at 4:58 PM, Joe Touch wrote: > Hi, Hemant, > > On 1/11/2017 8:51 AM, Hemant Singh wrote: > > I was looking at RFC3128. It's not specific to v6ops, but being a RFC > that covers TCP small fragment attacks, I thought I'd send the email. I > also think, the IETF WG that sponsored this RFC may be closed now. > > I wonder who approved this document because it has basic mistakes. > > (a) In section 2.1, the document uses "Fragment A" and also "B" for the > first time and does not define them anywhere. > > Presumably these refer to Fragment 1 and 2 as defined just above in the > same section (end of the previous page). > > (b) In section 2, in relation to Fragment 3, the document says "Fragment > offset >=2". In the IP header, the fragment offset is a multiple of 8 > octets, and thus == 2 is incorrect. > > The fragment offset field is indicated as a number of 8 octet units, e.g., > 0=0 octets, 1=8 octets, and 2=16 octets, so that is valid. That's why the > fragment field is only 13 bits long (vs. 16 bits to indicate the length of > an IP datagram). > > Please let me know if there is a current IETF WG covering such issues. > > INTAREA would be the relevant WG, but AFAICT you're pointing out something > we'd probably classify as an Errata, which wouldn't need to be addressed by > a WG. You can submit those here: > > https://www.rfc-editor.org/errata.php > > Joe > > > Thanks, > > Hemant > > > _______________________________________________ > v6ops mailing listv6ops@ietf.orghttps://www.ietf.org/mailman/listinfo/v6ops > > > --001a113b0a38e9114a0545e84960 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Joe,

Thanks much for your reply and als= o thanks to Brian.=C2=A0 Sure, even I surmised Fragment A and B as 1 and 2 = but I thought an RFC editor should have caught this minor issue.=C2=A0 Havi= ng seen Brian's reply related to individual submission, I see the editi= on issue.=C2=A0

=C2=A0I forgot to mention another = issue with RFC3128 in section 2.1.=C2=A0 Fragment 2 says target is telnet (= port 23) but then uses FTP in the sentence.=C2=A0 FTP should be "telne= t".=C2=A0 Sure, I will file an Errata.=C2=A0

= Thanks for the clarification on the number of 8 octet units.=C2=A0 Indeed, = the total length in the IP header is 2 bytes and thus the maximum packet is= 65536 but 13 bits only support 8192 bytes.=C2=A0

= I found that a cable modem is using 1480 in the fragment offset instead of = 185. =C2=A0 We should check what do router vendors do.

=

On a different note, see that RFC3128 references RFC185= 8 which lists the minimum size of an IPv4 datagram as 68 bytes.=C2=A0 Such = small packets are used to attack ACLs on firewalls for TCP packets using an= IP header which is 60 bytes in length.=C2=A0 Wonder what the minimum size = of an IPv6 packet is specified in any IPv6 RFC?=C2=A0 I checked the IPv6 No= de requirements RFC and don't find any minimum.

Thanks,

Hemant




On Wed, Jan 11, 2017 at 4:58 PM, Joe Touch <touch@isi.edu>= wrote:
=20 =20 =20
Hi, Hemant,

On 1/11/2017 8:51 = AM, Hemant Singh wrote:
I was looking at RFC3128.=C2=A0 It's not specifi= c to v6ops, but being a RFC that covers TCP small fragment attacks, I thought I'd send the email.=C2=A0 I also think, the IETF WG tha= t sponsored this RFC may be closed now.=C2=A0

I wonder who approved this document because it has basic mistakes.

(a) In section 2.1, the document uses "Fragment A" a= nd also "B" for the first time and does not define them anywher= e.
 Presumably these refer to Fragment 1 and 2 as defined just above in the same section (end of the previous page).

(b) In section 2, in relation to Fragment 3, the document says "Fragment offset >=3D2".=C2=A0 In the IP header= , the fragment offset is a multiple of 8 octets, and thus =3D=3D 2 is incorrect.=
The fragment offset field is indicated as a number of 8 octet units, e.g., 0=3D0 octets, 1=3D8 octets, and 2=3D16 octets, so that is valid. That's why the fragment field is only 13 bits long (vs. 16 bits to indicate the length of an IP datagram).

Please let me know if there is a current IETF WG covering such issues.
 INTAREA would be the relevant WG, but AFAICT you're pointing out something we'd probably classify as an Errata, which wouldn't n= eed to be addressed by a WG. You can submit those here:

https://www.rfc-editor.o= rg/errata.php

Joe


Thanks,

Hemant


_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/m=
ailman/listinfo/v6ops


--001a113b0a38e9114a0545e84960-- From nobody Thu Jan 12 09:54:39 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60F93129517 for ; Thu, 12 Jan 2017 09:54:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 wgQYAkm3cnRA for ; Thu, 12 Jan 2017 09:54:36 -0800 (PST) Received: from mail-qk0-x242.google.com (mail-qk0-x242.google.com [IPv6:2607:f8b0:400d:c09::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 143F312950C for ; Thu, 12 Jan 2017 09:54:36 -0800 (PST) Received: by mail-qk0-x242.google.com with SMTP id 11so3760717qkl.0 for ; Thu, 12 Jan 2017 09:54:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=5QpnBmBVoj1B9OHNR9mrUjvB1zDr67FPAdbUOxJ74f8=; b=vJvjTKJKSwjSeLTkjzS8Gw6vn7gAvBI0oNkqs3xtjh75Hpw5+X1CcBE9LOfZva76hy Dmh5zsYt6/xWgmUW5K0UmyBJ9fWS34mJ2qz2KNngtbNluEjSHGt3wNP4h24YfJF8o1up /Or/8BBZ3geBmBdKK6aXNqk3czqakt0oEelYQXoH0yUzmjJCYcKJAWXqCw25CqvUcxd6 biio3p7KODUT1eFpXtxhrR7bKvmV+taUNraRC6jgbrm1PhTCl35p3jwCtqv15HgY1plT /9EXqnehb3H949u7VBuKigD1p+GEMlgadcluVCEK587elAzUbdHUDL8QqixPS7TZDj69 kA8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=5QpnBmBVoj1B9OHNR9mrUjvB1zDr67FPAdbUOxJ74f8=; b=VCLkpAqHcSseu1vLN7Zm1tXCp5FdS6N8w8shiOexXVybmos82kb/NSYt4mlM7gtKMn qHX38fX4wZzNMLKfcPntYyTgoQomPWVD6y5n7m7O8iHPTdnDcu6KUUKw4B/cSmigbAQp FI8Z83Ck1Bq+3fDusHP5xYgWLf8OyewjBHvS+NGTiD02rdAlGp16vRpDzE/4bWAsoQc8 hWbtuoUU3g7ghfCZMPF1mif3M/KnVyb+H58giTV9zMDVHWcUCHnm3SFCyIPgjB2D26Kd naMEq1MsXTQafo3aJ4nLA6b/WS1jHzccEGD52sZUQ19q5DB5sUwCozPslqnRgLbuBEd1 Y9Xg== X-Gm-Message-State: AIkVDXK4+cr3JKAEs+NDlifUBi1VHbWVuuClEXqoWa9viO8VBC9BHo92qNMvY1FH0OBOhIWGJo1VXEf5jl4jJg== X-Received: by 10.55.45.129 with SMTP id t123mr13636713qkh.311.1484243675165; Thu, 12 Jan 2017 09:54:35 -0800 (PST) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.29 with HTTP; Thu, 12 Jan 2017 09:54:34 -0800 (PST) In-Reply-To: References: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Thu, 12 Jan 2017 09:54:34 -0800 X-Google-Sender-Auth: 6QP9tXiziewg49L6ZfjzKEo9v_U Message-ID: To: Ron Bonica Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 17:54:38 -0000 At Wed, 11 Jan 2017 15:37:08 +0000, Ron Bonica wrote: > Draft-ietf-v6ops-dhcpv6-slaac-problem was introduced 3.5 years ago, but has made little progress in the last year. Therefore, it become necessary for the chairs to reevaluate whether this draft should continue to be a WG item. > > If you have an opinion on this subject, please post it to the mailing list by 1/25/17. Options are: > Re-reading my own comments on the previous WGLC https://www.ietf.org/mail-archive/web/v6ops/current/msg24444.html (it's about the 06 version, but the latest 07 version seems to be almost identical to 06), I'd vote for > 1) Continue to work on the draft with an eye toward publication in 2017 *IF* (I guess this is a very big one) - we limit the scope of the doc to really practical issues. I gave specific suggestions in my previous LC comments. (I understand the definition of "practical" is completely subjective and others may have different definitions). - (assuming we still keep the appendix) we include at least one other open source system than Linux (which would most likely be some variant of BSD) -- JINMEI, Tatuya From nobody Thu Jan 12 10:49:15 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25839129435 for ; Thu, 12 Jan 2017 10:49:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.098 X-Spam-Level: X-Spam-Status: No, score=-10.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=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 I6_zzov8bbUz for ; Thu, 12 Jan 2017 10:49:11 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C0F3127078 for ; Thu, 12 Jan 2017 10:49:11 -0800 (PST) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v0CImdjl016951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 12 Jan 2017 10:48:39 -0800 (PST) To: Hemant Singh References: From: Joe Touch Message-ID: <6b761ce0-acb6-8e16-45c5-07fa9fa2f620@isi.edu> Date: Thu, 12 Jan 2017 10:48:39 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------B1D79228B63389C0F5135E54" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: v6ops list Subject: Re: [v6ops] TCP related attacks/RFC3128 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 18:49:13 -0000 This is a multi-part message in MIME format. --------------B1D79228B63389C0F5135E54 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi, Hemant, On 1/12/2017 8:34 AM, Hemant Singh wrote: > Joe, > > Thanks much for your reply and also thanks to Brian. Sure, even I > surmised Fragment A and B as 1 and 2 but I thought an RFC editor > should have caught this minor issue. Having seen Brian's reply > related to individual submission, I see the edition issue. > > I forgot to mention another issue with RFC3128 in section 2.1. > Fragment 2 says target is telnet (port 23) but then uses FTP in the > sentence. FTP should be "telnet". Sure, I will file an Errata. Makes sense. > > Thanks for the clarification on the number of 8 octet units. Indeed, > the total length in the IP header is 2 bytes and thus the maximum > packet is 65536 but 13 bits only support 8192 bytes. > > I found that a cable modem is using 1480 in the fragment offset > instead of 185. We should check what do router vendors do. The fragments would never reassemble - there would be a gap. You might check to see whether fragmented traffic fails as a result. > On a different note, see that RFC3128 references RFC1858 which lists > the minimum size of an IPv4 datagram as 68 bytes. The minimum IPv4 datagram would be 20 bytes - just the IP header with no data. 68 is the smallest IPv4 datagram that an IPv4 network MUST be able to transit without fragmentation. I.e., it's the minimum IPv4 MTU. > Such small packets are used to attack ACLs on firewalls for TCP > packets using an IP header which is 60 bytes in length. IMO, the only "attack" that exists for a firewall that can't handle 20 byte IPv4 packets at advertised line rate is on its consumers, i.e., they're lying about supporting IPv4 at the advertised line rate. IMO, any ACL system or firewall that claims to check for information that might not be in the initial fragment MUST perform reassembly. Although routers aren't supposed to do reassembly, a device that needs to inspect upper layer protocols is no longer just a router, and is acting on behalf of an endpoint and doing part of the endpoint's job. It thus is justified in reassembling before acting. > Wonder what the minimum size of an IPv6 packet is specified in any > IPv6 RFC? I checked the IPv6 Node requirements RFC and don't find any > minimum. The minimum packet size would be 40 bytes, i.e., just the IPv6 header with no data. That could be used to trigger a device or set off an alarm; there need not be any data for a packet to be useful. The minimum IPv6 packet that an IPv6 network MUST be able to transit without fragmentation is 1280, as specified in RFC2460. Joe > > Thanks, > > Hemant > > > > > On Wed, Jan 11, 2017 at 4:58 PM, Joe Touch > wrote: > > Hi, Hemant, > > On 1/11/2017 8:51 AM, Hemant Singh wrote: >> I was looking at RFC3128. It's not specific to v6ops, but being >> a RFC that covers TCP small fragment attacks, I thought I'd send >> the email. I also think, the IETF WG that sponsored this RFC may >> be closed now. >> >> I wonder who approved this document because it has basic mistakes. >> >> (a) In section 2.1, the document uses "Fragment A" and also "B" >> for the first time and does not define them anywhere. > Presumably these refer to Fragment 1 and 2 as defined just above > in the same section (end of the previous page). > >> (b) In section 2, in relation to Fragment 3, the document says >> "Fragment offset >=2". In the IP header, the fragment offset is >> a multiple of 8 octets, and thus == 2 is incorrect. > The fragment offset field is indicated as a number of 8 octet > units, e.g., 0=0 octets, 1=8 octets, and 2=16 octets, so that is > valid. That's why the fragment field is only 13 bits long (vs. 16 > bits to indicate the length of an IP datagram). > >> Please let me know if there is a current IETF WG covering such >> issues. > INTAREA would be the relevant WG, but AFAICT you're pointing out > something we'd probably classify as an Errata, which wouldn't need > to be addressed by a WG. You can submit those here: > > https://www.rfc-editor.org/errata.php > > > Joe > >> >> Thanks, >> >> Hemant >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > --------------B1D79228B63389C0F5135E54 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi, Hemant,


On 1/12/2017 8:34 AM, Hemant Singh wrote:
Joe,

Thanks much for your reply and also thanks to Brian.  Sure, even I surmised Fragment A and B as 1 and 2 but I thought an RFC editor should have caught this minor issue.  Having seen Brian's reply related to individual submission, I see the edition issue. 

 I forgot to mention another issue with RFC3128 in section 2.1.  Fragment 2 says target is telnet (port 23) but then uses FTP in the sentence.  FTP should be "telnet".  Sure, I will file an Errata.
Makes sense.

Thanks for the clarification on the number of 8 octet units.  Indeed, the total length in the IP header is 2 bytes and thus the maximum packet is 65536 but 13 bits only support 8192 bytes. 

I found that a cable modem is using 1480 in the fragment offset instead of 185.   We should check what do router vendors do.

The fragments would never reassemble - there would be a gap. You might check to see whether fragmented traffic fails as a result.

On a different note, see that RFC3128 references RFC1858 which lists the minimum size of an IPv4 datagram as 68 bytes.

The minimum IPv4 datagram would be 20 bytes - just the IP header with no data.

68 is the smallest IPv4 datagram that an IPv4 network MUST be able to transit without fragmentation. I.e., it's the minimum IPv4 MTU.

Such small packets are used to attack ACLs on firewalls for TCP packets using an IP header which is 60 bytes in length.

IMO, the only "attack" that exists for a firewall that can't handle 20 byte IPv4 packets at advertised line rate is on its consumers, i.e., they're lying about supporting IPv4 at the advertised line rate.

IMO, any ACL system or firewall that claims to check for information that might not be in the initial fragment MUST perform reassembly. Although routers aren't supposed to do reassembly, a device that needs to inspect upper layer protocols is no longer just a router, and is acting on behalf of an endpoint and doing part of the endpoint's job. It thus is justified in reassembling before acting.

Wonder what the minimum size of an IPv6 packet is specified in any IPv6 RFC?  I checked the IPv6 Node requirements RFC and don't find any minimum.

The minimum packet size would be 40 bytes, i.e., just the IPv6 header with no data. That could be used to trigger a device or set off an alarm; there need not be any data for a packet to be useful.

The minimum IPv6 packet that an IPv6 network MUST be able to transit without fragmentation is 1280, as specified in RFC2460.

Joe



Thanks,

Hemant




On Wed, Jan 11, 2017 at 4:58 PM, Joe Touch <touch@isi.edu> wrote:
Hi, Hemant,

On 1/11/2017 8:51 AM, Hemant Singh wrote:
I was looking at RFC3128.  It's not specific to v6ops, but being a RFC that covers TCP small fragment attacks, I thought I'd send the email.  I also think, the IETF WG that sponsored this RFC may be closed now. 

I wonder who approved this document because it has basic mistakes.

(a) In section 2.1, the document uses "Fragment A" and also "B" for the first time and does not define them anywhere.
 Presumably these refer to Fragment 1 and 2 as defined just above in the same section (end of the previous page).

(b) In section 2, in relation to Fragment 3, the document says "Fragment offset >=2".  In the IP header, the fragment offset is a multiple of 8 octets, and thus == 2 is incorrect.
 The fragment offset field is indicated as a number of 8 octet units, e.g., 0=0 octets, 1=8 octets, and 2=16 octets, so that is valid. That's why the fragment field is only 13 bits long (vs. 16 bits to indicate the length of an IP datagram).

Please let me know if there is a current IETF WG covering such issues.
 INTAREA would be the relevant WG, but AFAICT you're pointing out something we'd probably classify as an Errata, which wouldn't need to be addressed by a WG. You can submit those here:

https://www.rfc-editor.org/errata.php

Joe


Thanks,

Hemant


_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--------------B1D79228B63389C0F5135E54-- From nobody Thu Jan 12 11:31:41 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF7DD1294E3 for ; Thu, 12 Jan 2017 11:31:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 NIwB2z0SUNBm for ; Thu, 12 Jan 2017 11:31:38 -0800 (PST) Received: from mail-pf0-x242.google.com (mail-pf0-x242.google.com [IPv6:2607:f8b0:400e:c00::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B3EA1293E0 for ; Thu, 12 Jan 2017 11:31:38 -0800 (PST) Received: by mail-pf0-x242.google.com with SMTP id f144so4722999pfa.2 for ; Thu, 12 Jan 2017 11:31:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=jiMTQKpk6O4B6CudCSPRuOxoMhz8NNzbmPRveTo83lw=; b=nRBGBqBEt0deypy0rYUtJLtMempb2uJPiqtb/c8DUjwXiHwKBDokw+CGP2/UAHM2VU BMR7A3mpAXmLjyOhLeMGi8qAEM/mGZZhk1zMFSEp+vrIBpJmSU9L3vDUTD+8dzHRdOPQ i+Ih+I36zWOZ2nUHsqSPRt6kI5Up32D3CXJD2/8W4DlQu5rRt1pO1a//ZkvqLa0xSLyv QsGDPTr5zMoWOOV2iOz+CrPZ62XEsnCtiycCV8bM5rdH1aDdA19lTl8C5Qvp5mrWoHxj lLBTWZm0n8/dJ1Uxx6FLSbYjjmrCxCK+kDz06tX/ZyahWEDNGuvVDTIjNC28KXLES/v/ Kyvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=jiMTQKpk6O4B6CudCSPRuOxoMhz8NNzbmPRveTo83lw=; b=eHc5CXAT5EnrrxB5hQnTMJRHyWrJC+ihUf1s6dT8GlKP/JwH388qZaqJeKkE5QUJ+E NdTdTb7KRvVEA/oTCR1f0I7GuawdBh8hWl7D9kC18Pnom64wx5I5Y8rel+EHRqaWuFdh VPEvrr65lXTCMS8+LX8A/tpJeQmTBKayQSZD551HP7CsW6oVn7e3eAX6EIqOYq/x1yx1 02xsL2vXWZZX5EiAZxmbFCRGyCNlZ/hPCNbFubeATZs3TitKD0guRTtW3a1DCvW8pGzp PG+GVj0UB9RJ4uTMUTgDLUjQYIMkCMW4/1KyHDcqgNyzEPHzhXI4XNol+TLVJIgOJbyr jYrw== X-Gm-Message-State: AIkVDXKKfCTMLeqwuECTzYIydywbyYKiCY+fAr2kPmVwQfwO3tX+61uJLpL32sXymwBmHw== X-Received: by 10.84.210.35 with SMTP id z32mr23882017plh.112.1484249497457; Thu, 12 Jan 2017 11:31:37 -0800 (PST) Received: from [192.168.178.21] ([118.148.127.232]) by smtp.gmail.com with ESMTPSA id z77sm23568529pfk.47.2017.01.12.11.31.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Jan 2017 11:31:36 -0800 (PST) To: Fernando Gont , otroan@employees.org References: <89c6a9a4-e561-dee3-8899-17ae50ae4c2a@gmail.com> <44FCCC34-7995-4E10-85E9-58C08C371416@employees.org> <0453eb8d-757a-38c5-6e7e-40bda416acba@si6networks.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Fri, 13 Jan 2017 08:31:41 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <0453eb8d-757a-38c5-6e7e-40bda416acba@si6networks.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 19:31:40 -0000 On 12/01/2017 22:51, Fernando Gont wrote: > Hi, Ole, > > On 01/12/2017 05:45 AM, otroan@employees.org wrote: >>> This draft describes real issues but the information is a bit out >>> of date. Can we ask the authors to confirm that things are still >>> the same for current o/s releases? Then publish quickly so that we >>> can start the *real* discussion: how to fix? >> >> This draft shouldn't be gating any real discussion. If there are >> solutions please offer them now. > > Noting the problem, and providing datapoints is useful, IMO. > > > >> I have read through the draft again. While the draft has some points, >> these are issues that has been discussed extensively. I struggle to >> see how this will lead to and "fixes". >> >> I have a suggestion. Given that we have beaten on this particular >> horse a lot over the last 15 years. Could we redo this draft into a >> "Why?" draft in the style of RFC7421? Explain the issues, explain the >> design choices and why the mechanisms function as they do, but don't >> phrase it as a problem that needs to be fixed. > > The fact that you get different outcomes for different systems, setups, > etc., does not seem nice to me. Yes, that *is* the problem. And, while I agree with Ole's points about how to improve the document by making it more explanatory, I think documenting the problem properly is necessary before proposing fixes. > As to the why...I wonder if a "well, there's the slaac folks, and the > dhcpv6 folks..." document would be "publishable".. That's a *different* document, and I think the issue there is what Randy Bush mentioned recently on another list: we don't offer feature-equivalence between DHCP and DHCPv6, but sites that rely on DHCP operationally want feature-equivalence, and they are the customers, and customers are always right. Brian From nobody Thu Jan 12 11:49:03 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60905129493 for ; Thu, 12 Jan 2017 11:49:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 e9uaUEBm7QZQ for ; Thu, 12 Jan 2017 11:49:00 -0800 (PST) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E50A1293E0 for ; Thu, 12 Jan 2017 11:49:00 -0800 (PST) Received: by mail-ua0-x22f.google.com with SMTP id 96so21985539uaq.3 for ; Thu, 12 Jan 2017 11:49:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=/L747FUKk3thKIHYFW23VmHnN/onuScTqH3q+Us4Q0g=; b=hI+xHgIpp0zaPdW85GtBZElvVm2nuo8Db1lDcWpxdU9do0I3NpaRXkeHaVeOIhYO3c 1JwXx3vocTqwLw67jJobrX32DI2arfjiqMbQwnf6xlCjTo8xZ3kz4Js5bh5VpAZgpvTu S+9s+okVV+dQy50BZzIzez0377SwW5q2Q62QS8mXpTbfK8jqP+53UBxPwJQojJXJ2ZLx OlKeo/qd8o4zGLHWAGuxiDjYfrBlwjvBCaZse4wK+s64f7PYh2Ef8tdWs6FYzl75Ev9/ xwf63hsy5FMtbQgVRzRIbJEZVgBXu8/ssgIdY10JCSdpPzyLzCJqR3ul39UK2IQbGxwG pUJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=/L747FUKk3thKIHYFW23VmHnN/onuScTqH3q+Us4Q0g=; b=IH/5RaJ7UL872nhalSsyB9RDq+eRfElOseSQefbPAz5jPT/pPe/AcoG0H5duFUNo4l L7TG5YwPMtVjdxZ/dW3x5PsgqM7qi0xkp840nUfmoTrdg4zuB5NAwgUNa458xTUr5kzt J6V/zzsemuzsY3IbN+Cs5OmGJbw40iq3tlYPg/n9Tdm8nJp75tgQKqgx225tU59wX2bg Zq2ygRtPUviG6Sa2NXbOkHWUH7qxke4pCDucgRR/Pw4RuBh2BDIdcRAkxGtpCOqarZYY QKsRSqJ98A1aj479JUSRl5JoofKNU2uKXPyi6gwC+uI2Tjun1l7WwuIRuVZ/gFGDI7X+ /VSw== X-Gm-Message-State: AIkVDXK2Pd4RBm/Tr4KsP9v4iEUVJ0DNataU3WBq8Ycy1Ww3y/Ic95600KO9jS7UzK2CLHDYv0SHVVpCxXj22A== X-Received: by 10.159.40.194 with SMTP id d60mr8514195uad.122.1484250539527; Thu, 12 Jan 2017 11:48:59 -0800 (PST) MIME-Version: 1.0 Sender: fgont.mobile@gmail.com Received: by 10.103.21.67 with HTTP; Thu, 12 Jan 2017 11:48:58 -0800 (PST) Received: by 10.103.21.67 with HTTP; Thu, 12 Jan 2017 11:48:58 -0800 (PST) In-Reply-To: References: <89c6a9a4-e561-dee3-8899-17ae50ae4c2a@gmail.com> <44FCCC34-7995-4E10-85E9-58C08C371416@employees.org> <0453eb8d-757a-38c5-6e7e-40bda416acba@si6networks.com> From: Fernando Gont Date: Thu, 12 Jan 2017 16:48:58 -0300 X-Google-Sender-Auth: D_cvMl6QkQhs1vcSiPBGBhhBUhU Message-ID: To: Brian Carpenter Content-Type: multipart/alternative; boundary=94eb2c1245be2a90ff0545eb026b Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 19:49:02 -0000 --94eb2c1245be2a90ff0545eb026b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable El 12/1/2017 16:31, "Brian E Carpenter" escribi=C3=B3: On 12/01/2017 22:51, Fernando Gont wrote: > Hi, Ole, [...] > The fact that you get different outcomes for different systems, setups, > etc., does not seem nice to me. Yes, that *is* the problem. And, while I agree with Ole's points about how to improve the document by making it more explanatory, I think documenting the problem properly is necessary before proposing fixes. Agreed. > As to the why...I wonder if a "well, there's the slaac folks, and the > dhcpv6 folks..." document would be "publishable".. That's a *different* document, and I think the issue there is what Randy Bush mentioned recently on another list: we don't offer feature-equivalence between DHCP and DHCPv6, but sites that rely on DHCP operationally want feature-equivalence, and they are the customers, and customers are always right. I.agree here, too. I've talked to at least a few operators and they don't understand why they can't get a dhcpv6 that does the same job as dhcpv6 -- even less why, in practice, they have to resort to doing dhcpv6 + slaac (both!) Cheers, Fernando --94eb2c1245be2a90ff0545eb026b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


El 12/1/2017 16:31, "Brian E Carpenter" <brian.e.carpenter@gmail.com> esc= ribi=C3=B3:
On 12/01/2017 = 22:51, Fernando Gont wrote:
> Hi, Ole,
[...]
<= blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc = solid;padding-left:1ex"> > The fact that you get different outcomes for different systems, setups= ,
> etc., does not seem nice to me.

Yes, that *is* the problem. And, while I agree with Ole's points about = how
to improve the document by making it more explanatory, I think documenting<= br> the problem properly is necessary before proposing fixes.
<= /div>

Agreed.


=

> As to the why...I wonder if a "well, there's the slaac folks,= and the
> dhcpv6 folks..." document would be "publishable"..

That's a *different* document, and I think the issue there is what Rand= y
Bush mentioned recently on another list: we don't offer feature-equival= ence
between DHCP and DHCPv6, but sites that rely on DHCP operationally want
feature-equivalence, and they are the customers, and customers are always right.

I.agree here, too. I've talked to at least a few = operators and they don't understand why they can't get a dhcpv6 tha= t does the same job as dhcpv6 -- even less why, in practice, they have to r= esort to doing dhcpv6 + slaac (both!)

Cheers,
Fernando







--94eb2c1245be2a90ff0545eb026b-- From nobody Fri Jan 13 04:30:51 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F386129B5D for ; Fri, 13 Jan 2017 04:30:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com 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 Y3kgRtNdbU-B for ; Fri, 13 Jan 2017 04:30:48 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0122.outbound.protection.outlook.com [104.47.2.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93382129432 for ; Fri, 13 Jan 2017 04:30:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=2dHnQbBZhdbbN1FXSaTMrpVVQlVsRsH/UGzs46ve/wI=; b=JmRQWk+jwBrEqOv+s+trkVJGRL/0Fzt/gqp+pdMHmw9vw0Xk6S/SKNlWrR0RciL7mIzHGDPTwmqqq2Qu2STCnbB94OcZakbeFEHas5+ftTyRV0EJlE11n0vIFMwLyVeuO1DlhktEoRyyNtn4R8jlvAqTSRwFcxhYHwuEYuX5/qM= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (81.135.210.62) by HE1PR0701MB3003.eurprd07.prod.outlook.com (10.168.93.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.845.6; Fri, 13 Jan 2017 12:30:44 +0000 Message-ID: <044101d26d98$9ebfeb40$4001a8c0@gateway.2wire.net> From: t.petch To: Brian E Carpenter , Ron Bonica , IPv6 Ops WG , Fernando Gont References: <89c6a9a4-e561-dee3-8899-17ae50ae4c2a@gmail.com> <737ab45e-0323-2653-f6d6-39268a393625@si6networks.com> Date: Fri, 13 Jan 2017 12:01:06 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.135.210.62] X-ClientProxiedBy: DB6PR0301CA0011.eurprd03.prod.outlook.com (10.168.49.21) To HE1PR0701MB3003.eurprd07.prod.outlook.com (10.168.93.137) X-MS-Office365-Filtering-Correlation-Id: 71f079ee-b087-4fb0-3f67-08d43baffef1 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:HE1PR0701MB3003; X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3003; 3:cu4o/6rU/AxVHjIW+21KkHzORPsvAikhgeDXKyrOaoIXv8cTLMRJS/CtucLw7DnvYi/LY/XSKNy0yZl1Yu/nNFl6t1mzy3Yky7P1p2o2Nuwso3OOMS1KL6d/TJBAmYWDSOQE0/IpOFQNpC7Gf9VPPDGBrASM++a0qIix0pEx1xoliuNBRI/eflbwkhktdwoq0eqws4+OyIhJAoqWnldUAe9QUVz//g+tHq4uQBUpVXnoc1Qqmdj9lDVkUY9UpApgJvaK2R90XN0l/ZBgRWoM+Q==; 25:BTkyidIHvS4qyez5ttIehiZDYFtBnPCR1EDSd2IMeotkw6uCVp2MBjkQ+sECE5HyI1iUw3okm9QcF8xhYNkBMvLpYccadr2y12H3SkqGdl7ALYemcelM1z+vRHtsHAVdzprKrjY4UGs8Pgs91tjm9Fp1KBPK9WatAojbObV3dlCT8qpcVokLEw/2TDx+QeeOGxvPHJZvBFLZVHL0GkNhakBtZnbNokzmjJQFfgKce7wid5e/PfMhoYfBAilb6WZkuMfR2KZIqMeerHPNw6fPmImsOIF4mz9KTEbki6tyoi3s0gtxvSvt3lkEF4/4c3cxzkDUOR2v20f7rvtiaGp6sF7RA0ICNdXLCOOl5JFMurXfiXm6Zs+IWrGr6zaF2hdD1wYGg4b25quDETL2Avt3VcXVbveLEfPWsGnAAOJmSuFebSfs/Rc7wFpPvIk2FdVUZ0R6Zu0ZiGtpp0yZreFN/g== X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3003; 31:sZNp8qbwkYlo8wh3+f0bOvcR8MXRCtsfg5+mpSoqfNCJ/wcIWAw97uizdtZ0ohqEzE6Sum5ZwPnrf9i9RBhMHkO1vYwNql3FE8YPIBn6CYFPBAB0p4et9twFJxrpFMPpegGGccZTjyJYB1vK1P9DL+JkD9++5E13L7GtLftq3AviLgFhBirnQJx4IPOLyJ8Ot6+eUEYrwXSyoqkNnUNP8MkLsElvYIZGxALYasElIq0bT4XDGuVv4ZcpU0t0bdhkhOmeyAK0juz9leCb/fqT+ebx44fOHcNvWfsgrcg3la0=; 4:prX78yI4B++t0+AxYZwOq4LBF0nXbuV16GHthz24xVsOJjwtJEPhu2Ws0qcIvaKh42YdqN3IbRb0zpZ5i+0fju2I5DtRiDnIokLkWBxR0DDFbcjDJRZbf7Qh2x+u50hNfijf2ySB7UxmNfBHhemliteSimRfZlm8J709DIpqrpeyeMZgsZ3aO6vXUO8JZtrxP+ffDeaR/fVnWOFtcf0XgzO6LQFRaNZ+R/3QdCoFJSX06e5spVa425NfLC2awAsBc5g6d6iXKrXHmp1uh8THVZzdFUclFBK3fxwMqUC9VJcPzz3DucNp4TDVFOiMxa2KJVP/aDq4gtr97WD582ncDqklsRxS66j9ui015cVRRX7jtdMo9wT9r8NQ0owOdMyPNjXwQ470v9Nm7yoS3ke4+nDUV35YKyekIOAJ7GxmjV3k4pjntyFdP2KVKw8lXuzGIsPzyu8hWEyWely2PAGn0i4GveHqoABU/eQBP+VcyoARs5e//Dq/KVG8Ps2hIlb5slsadiv2RL5rv2Q6sAqL8kGTVQVDz9C+dn5sKyV8FwZMvyspAazSUoIad+agxB7MfXtWXJi1hDIvVrUf1uTL0A== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123562025)(20161123564025)(20161123560025)(20161123555025)(6072148); SRVR:HE1PR0701MB3003; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB3003; X-Forefront-PRVS: 018632C080 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(39450400003)(189002)(13464003)(377454003)(199003)(252514010)(24454002)(8666007)(6496003)(33646002)(229853002)(86362001)(44736005)(5660300001)(39060400001)(189998001)(116806002)(6486002)(6666003)(81816999)(38730400001)(25786008)(66066001)(50466002)(107886002)(23756003)(8676002)(4720700003)(92566002)(47776003)(9686003)(42186005)(81166006)(1941001)(62236002)(44716002)(61296003)(50226002)(81156014)(84392002)(105586002)(2906002)(106356001)(230783001)(101416001)(68736007)(5001770100001)(81686999)(14496001)(1456003)(50986999)(76176999)(97736004)(230700001)(305945005)(6116002)(1556002)(3846002)(7736002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB3003; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; HE1PR0701MB3003; 23:dXFtyropvjK+gKGAExZMTBSP6jO3TnQ4Lrq2c?= =?iso-8859-1?Q?WsiuUpHI3T6KYetD7ruRdNCj+SHXedRp3ZWnak3zU8Ogk64NCa0AxRM/Yg?= =?iso-8859-1?Q?UI1nGw1INWoeF0v1a1L/qkE7tarJrojUuLvKcifumTEQXxtxt6hMpXfsuP?= =?iso-8859-1?Q?V7SYN+nKWC30SM9EXKpYw2xzpRTNBsp9uUJqSkdcid3iKh4CPORLJHNTNy?= =?iso-8859-1?Q?9ySgvVWMgLLnGWuMQ1Zo/hG/UTrGdYFFLHly6ypbMVCYyP1bsr7uiqyUlz?= =?iso-8859-1?Q?WBIbvqLwD4V38OkjPPEnbZA7qaIWBRD7DeGiT2sMKye4zZ8uiNVW0bPY4z?= =?iso-8859-1?Q?Gdi7Iy4SimKhsKEObbByAt9AVwt92t1P9lWzi5XX3U8obkh52W2nmt7sRw?= =?iso-8859-1?Q?1JphPqc3dTyUOl2k/u9H9nBCWYTRneqTi9yXm5fTe+pQUe6BZ2YAhp7Xs5?= =?iso-8859-1?Q?UwhtDVbrIZcqlHgB/ObG+C+CEjHzGZsindV8rLfZHEQGr+rJMOmKg1voWW?= =?iso-8859-1?Q?ny3RgrmVyex4fus3FJtBDC//cA+7BRRUDo5xEzDry0YOE+S6TcXLNMgbEq?= =?iso-8859-1?Q?/k+MSqHk99HcKmbCKfYMzmWu5mUe5lBzxGCEtXwu4Ofaqy1plaURGhvpuB?= =?iso-8859-1?Q?CUVtGmKte2XJ2IqvJkm3HsoJmrSYxXPnlleqSiNN0fRZApIrnezrr2yXLl?= =?iso-8859-1?Q?wjop3xSfzM5cl4KpdqX/34BJKF8LpysQhSGHBHbGexPrioEIZNbWqhZJia?= =?iso-8859-1?Q?OecSfcWDU5/R1XDF4nwHVt+eOdP9tNBhoBV5UCs/JyPTM3xJdQin8y011J?= =?iso-8859-1?Q?MMkwypBk9JYu4yVU2fLXax36mvMB8mOU266goyuDh1TN7fcvaZgFLoJCKd?= =?iso-8859-1?Q?4eiEcoQ+ZdzxV7qfl5YxyFgHT2P+ID4X9FjD9Zb1sv0vskT2+ifrAeWEIQ?= =?iso-8859-1?Q?INLiislOs48Bz9f0uqce83Fj3mHcsatuv/c6ySePI8SgPsRlvFu5ih3pPe?= =?iso-8859-1?Q?BCOvpFJa3k33vnJ4E+xLe4kys/P/qrciLsF1pwbIHfEwoOxH64yYIn7kay?= =?iso-8859-1?Q?BypeNJoFyX/XQCX7lF6POcuNZs/jq1Hb1lXvhbJw7ZHfbwf4XgL7bwf/ux?= =?iso-8859-1?Q?JLITfYGc/Y3LMul693LMvKjJuSiVjpkjkNqJJHi3PiWH4fR0Hwumg3chtc?= =?iso-8859-1?Q?dAAb70DZSaVnzmhHD7/3OvZXy6ti3RC1sOww9S6382KFQWrLy2VAT/lokN?= =?iso-8859-1?Q?ttAO1BewUCiWV+DNoVaDSSA7TfRf1FaJ17emnEwXdylnE/qSoqwy3HtSmb?= =?iso-8859-1?Q?zwbV8dDE+vp/HmgU/5Mw/pXLsak/696EeGJSUyYJQSVSMkIb20orLGmVK6?= =?iso-8859-1?Q?6n/aVkn86NlTINTOkyW43zj4m0/p7z4GngylO3y5I0ZCGvmEsuFmwpbGAp?= =?iso-8859-1?Q?b1hRqhKX/JFVTB2mBsmoCIMl0rRIHQlMpTuBh0/C2owveswSS4NGHuvHU1?= =?iso-8859-1?Q?1aOHyrGAh/Gzp+Njnb3okl+Fzn17dG3WeC+6EqSPdgyUJNTk1xV96XAWez?= =?iso-8859-1?Q?4UFM5pi4OwOcbheGS0Tx0zeAnO6Y=3D?= X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3003; 6:js3ULRqrvy6o26F9g0trh5i4Pve1g8mT+DXlnJoRSSeIpxreQrnvxc2AArCkIKjRotOf2OvrPVUBMwom8RrcaKLgoR6dNdPTfsT77S25ema9XkOkjEfGh4PMbwZA9R8CZpTmMmdLsR4dR9qh9tTomCQbfmsXMVHEUTAL6Eb8Rq0ZvVmqGww3F9li7t2e/nGnRjYBfz3FRfv8tUO2MUs5+rbcZ2XJmpFgvCg9ta4kY9PT4NwdTNJB/PrvECOStuz6n1gO05Z7uBf+dzxXb+OMCfmcvSq7MRk/9Qd5kZXMPt/ff6tz5x4L/oKw1vUnLBZmAz+GtgMM6aM9dc1I4Yj5SDtnjxz63jUf7P82hI35yCg9O9qtnSkYV9qSO7maq1+nrr6XLy/RDN9w7yOqbUS/Q08S4T2U5U9AWLDID5wCXNA=; 5:CamQaqUb//FLNBq1Vj3ZmCc+EbKC6kQqJ6XRAcLEXiau5sFHVjQEsMfVJQfbaYbcgM85gG2KlXSQ0nlv1lvDz/kdr9nbe+22Ox7fuDptvn+qle6iroZAHTF9lCx0h7KK8NgjpuTLMBl82FwcyD5pe+zgZsnm4DCnNzlJVAAkHRg=; 24:CTOFMh2vus4YvwDw0xWizt3vzdTn2xB5MNINZKkKxaJ44vyNvDe3M1HWEoYHkUPHkVi6cJss7Ay4LTiSyse0X942FZ7EFKjfEH2ppCkZve0= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3003; 7:vJa78jOJhpy1Rxps0+D5tG0E11AMOorOv1W+uFjz+Zy6g07yyI8KmSmi7CSO8h2oOK/yO+PI6WB3QvTynN8kaGMoc4nXrE9QFRcuhZ4g4VefgPdhN/jMnKs+q8xZqYFyy4u+hujY/KAb05HxhZJLXGhoUzH0ScDjczZLoZhllOJqAsh/Fp8hmNRswqv9NDG9ex7XgWwdZhQXATU8Ulz2S9TfBT8LxIO1TgHUBkNF+QMG9TIDOn4SOmkSfG0828XK4/FMgQbKjup9Rnmu83PuqezZ43ls1Bivb26PuXro2RI1Qqd8u3b0jCZ7djsT8ZBFexggp59+T5ixrrnwlDE6YDWqyAJnbYqUMydrNaE8dNr+2OMQLDzFrF9zyASWIGlwYWZkvn0SAlBlrUvH3CHaoo74O8qj6FwJSXwpK06SNXgcajsCcdDfDPXvcdXGyZt2n71slSDrse0JfS4KUf7upA== X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jan 2017 12:30:44.2686 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB3003 Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 12:30:50 -0000 ----- Original Message ----- From: "Fernando Gont" Sent: Thursday, January 12, 2017 9:47 AM > On 01/11/2017 05:42 PM, Brian E Carpenter wrote: > > This draft describes real issues but the information is a bit out of > > date. Can we ask the authors to confirm that things are still the > > same for current o/s releases? Then publish quickly so that we can > > start the *real* discussion: how to fix? > > I'd agree with Brian. -- but also please keep the data for the OS > releases/versions listed in the I-D. All of them are useful. I suggested publishing it as Historic because: - it gives a good description of the behaviour of Windows 7 which has been replaced in many respects by Windows 10 (much as that release is disliked) so I cannot see the document as current without coverage of Windows 10 - I do not see the authors having the energy to do the work on Windows 10 - the impression I got from this list is that their energy started to flag in 2014. Tom Petch > Thanks, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Jan 13 18:06:37 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A6CD129622 for ; Fri, 13 Jan 2017 18:06:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.42 X-Spam-Level: X-Spam-Status: No, score=-7.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 kr-nDUBqXFgy for ; Fri, 13 Jan 2017 18:06:34 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67E55129476 for ; Fri, 13 Jan 2017 18:06:32 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CYT39588; Sat, 14 Jan 2017 02:06:29 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.301.0; Sat, 14 Jan 2017 02:06:29 +0000 Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Sat, 14 Jan 2017 10:06:24 +0800 From: "Liubing (Leo)" To: "t.petch" , Brian E Carpenter , Ron Bonica , IPv6 Ops WG , Fernando Gont Thread-Topic: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem Thread-Index: AdJsHl8ei2TWu3IlRCWkCcSkighPWf//07eAgADbE4CAAkZNVv//Ipog Date: Sat, 14 Jan 2017 02:06:24 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45C2E97A15@nkgeml514-mbx.china.huawei.com> References: <89c6a9a4-e561-dee3-8899-17ae50ae4c2a@gmail.com> <737ab45e-0323-2653-f6d6-39268a393625@si6networks.com> <044101d26d98$9ebfeb40$4001a8c0@gateway.2wire.net> In-Reply-To: <044101d26d98$9ebfeb40$4001a8c0@gateway.2wire.net> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.191.175] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0207.587987A6.0068, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 3660c6fd36bf8cb9055cb086af10dcdb Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2017 02:06:36 -0000 Hi Tom, -----Original Message----- From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of t.petch Sent: Friday, January 13, 2017 8:01 PM To: Brian E Carpenter; Ron Bonica; IPv6 Ops WG; Fernando Gont Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem ----- Original Message ----- From: "Fernando Gont" Sent: Thursday, January 12, 2017 9:47 AM > On 01/11/2017 05:42 PM, Brian E Carpenter wrote: > > This draft describes real issues but the information is a bit out of=20 > > date. Can we ask the authors to confirm that things are still the=20 > > same for current o/s releases? Then publish quickly so that we can=20 > > start the *real* discussion: how to fix? > > I'd agree with Brian. -- but also please keep the data for the OS=20 > releases/versions listed in the I-D. All of them are useful. I suggested publishing it as Historic because: - it gives a good description of the behaviour of Windows 7 which has been = replaced in many respects by Windows 10 (much as that release is disliked) so I cannot see the document as current without coverage of Windo= ws 10 - I do not see the authors having the energy to do the work on Windows 10 - the impression I got from this list is that their energy started to fl= ag in 2014. [Bing] We made an essential update on 05 version (June 2015), then the docu= ment was stalled and the last two versions were keep-alive.=20 But if the WG would like to move forward it, we'd be glad to update the tes= t of the latest OSes. Best regards, Bing Tom Petch > Thanks, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Jan 13 20:16:16 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52A1C1297C1 for ; Fri, 13 Jan 2017 20:16:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.42 X-Spam-Level: X-Spam-Status: No, score=-7.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 UQ2iN8J32KF1 for ; Fri, 13 Jan 2017 20:16:12 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B38E812979D for ; Fri, 13 Jan 2017 20:16:10 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DEK06756; Sat, 14 Jan 2017 04:16:08 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.301.0; Sat, 14 Jan 2017 04:16:07 +0000 Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Sat, 14 Jan 2017 12:16:03 +0800 From: "Liubing (Leo)" To: "Bernie Volz (volz)" , Tim Chown , Ron Bonica Thread-Topic: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem Thread-Index: AdJsHl8ei2TWu3IlRCWkCcSkighPWQAg46IAAAG7nIAAWw9NgA== Date: Sat, 14 Jan 2017 04:16:02 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45C2E97A5F@nkgeml514-mbx.china.huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.191.175] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.5879A608.0106, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: fabef7d47426ae4b732fe11333ec7a65 Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2017 04:16:15 -0000 SGkgQmVybmllLA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogdjZvcHMgW21h aWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQmVybmllIFZvbHogKHZv bHopDQpTZW50OiBUaHVyc2RheSwgSmFudWFyeSAxMiwgMjAxNyAxMTo1MyBQTQ0KVG86IFRpbSBD aG93bjsgUm9uIEJvbmljYQ0KQ2M6IElQdjYgT3BzIFdHDQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBk cmFmdC1pZXRmLXY2b3BzLWRoY3B2Ni1zbGFhYy1wcm9ibGVtDQoNCkhpOg0KDQpJIGFsc28gd29u ZGVyIGlmIHRoZXJlIHdlcmUgc29tZSBwcm9wb3NlZCDigJxmaXhlc+KAnSwgcGVyaGFwcyB0aGV5 IGNvdWxkIGJlIHdvcmtlZCBpbnRvIHRoZSAzMzE1YmlzIChhcyB0aGV5IHJlbGF0ZSB0byBESENQ djYpLiBFdmVuIGlmIHdlIGRpZG7igJl0IGhpdCBldmVyeXRoaW5nLCBpbXByb3ZpbmcgdGhpbmdz IGEgYml0IGlzIGJldHRlciB0aGFuIG5vdCBhdCBhbGw/IEJ1dCB0aGlzIGFsc28gbWlnaHQgbm90 IGJlIHRoZSBiZXN0IGF2ZW51ZSBhdCB0aGlzIHRpbWUsIGdpdmVuIHdoZXJlIHdlIGFyZSB3aXRo IHRoZSAzMzE1YmlzIHdvcmsuIEFuZCwgSSBjZXJ0YWlubHkgZG9u4oCZdCB3YW50IHRvIHN0YXJ0 IGEgbG9uZyBkZWJhdGUgb24gdGhlIE0mTyBiaXRzLg0KDQpQZXJoYXBzIGlmIHRoZSBhdXRob3Jz IGhhdmUgYSBsaXN0IG9mIGEgZmV3IHJlY29tbWVuZGF0aW9ucyBmb3Igd2hhdCB3ZSBtaWdodCBp bmNvcnBvcmF0ZSBpbiB0aGUgMzMxNWJpcyBkb2N1bWVudCwgd2UgKGNvYXV0aG9ycyBhbmQgREhD IFdHKSBjb3VsZCByZXZpZXcgdGhlc2UgYW5kIGlmIHRoZXJlIGlzIHN1ZmZpY2llbnQgY29uc2Vu c3VzIHVwZGF0ZSB0aGUgZG9jdW1lbnQgYWNjb3JkaW5nbHk/DQoNCltCaW5nXSBJIHRoaW5rIHRo ZSAiZml4ZXMiIGlzIG1vc3RseSByZWdhcmRpbmcgdG8gTkQvU0xBQUMsIHNpbmNlIE0mTyBpcyBp biBSQSBtc2cuIEhvd2V2ZXIsIHRoZXJlIGFyZSB0d28gY2FzZXMgZGVzY3JpYmVkIGluIHRoZSBk cmFmdCB0aGF0IG1pZ2h0IG5lZWQgREhDUHY2IHRvIG5haWwgZG93biB0aGUgYmVoYXZpb3I6DQot IFdoZW4gdGhlcmUgaXMgbm8gUkEgbXNnDQpXZSBzYXcgc29tZSBMaW51eCBqdXN0ICJsYXp5Iiwg d2hlcmUgdGhlcmUncyBubyBSQSwgdGhlcmUgaXMgbm8gREhDUHY2OyB3ZSBhbHNvIHNhdyBzb21l IG90aGVyIE9TIChXaW5kb3cgOC4xKSAiZGlsaWdlbnQiLCB0aGUgREhDUHY2IGNsaWVudCBqdXN0 IHN0YXJ0ZWQgYXQgdGhlIGJlZ2lubmluZyByZWdhcmRsZXNzIG9mIFJBIG1zZy4NCkJ1dCBmcm9t IHByYWN0aWNhbCBwZXJzcGVjdGl2ZSwgIm5vIFJBIiBpcyBpbnZhbGlkIGFjY29yZGluZyB0byBj dXJyZW50IHN0YW5kYXJkcywgc2luY2UgREhDUHY2IGNhbm5vdCBjb25maWd1cmUgZGVmYXVsdCBy b3V0ZS4gSG93ZXZlciwgY29uc2lkZXJpbmcgZnV0dXJlIGRldmVsb3BtZW50IG9mIERIQ1B2Niwg bWF5YmUgaXQncyBnb29kIHRvIGNsZWFybHkgc3BlY2lmeSB0aGF0IHRoZSBESENQdjYgY2xpZW50 IE1VU1Qgc3RhcnQgaWYgdGhlcmUgaXMgbm8gUkFzIGZvciBzb21lIHRpbWUgKGUuZy4gMzBzLCBv ciBldmVuIHNob3J0ZXIpLiANCi0gV2hlbiBNIHRyYW5zaXRpb24gZnJvbSAxIHRvIDANCldlIHNh dyBXaW5kb3dzIDcgaW1tZWRpYXRlbHkgcmVsZWFzaW5nIHRoZSBESENQdjYgYWRkcmVzczsgd2Ug YWxzbyBzYXcgTGludXgganVzdCBpZ25vcmUgdGhlIHRyYW5zaXRpb24uIFdpbmRvd3MgNydzIGJl aGF2aW9yIGlzIGJhZC4gSSB0aGluayBESENQdjYgbWlnaHQgbmVlZCB0byBleHBsaWNpdGx5IGFi YW5kb24gdGhpcyBiZWhhdmlvci4NCg0KQXBhcnQgZnJvbSB0aGVzZSBzcGVjaWZpYyBiZWhhdmlv cnMuIE9uZSBnZW5lcmFsIGNvbW1lbnQgaXM6IHdoaWNoIG1vZHVsZSBpbiB0aGUgT1MgaXMgcmVz cG9uc2libGUgZm9yIG1vbml0b3JpbmcgdGhlIE0mTyBiaXRzPyBJZiBpdCBpcyB0aGUgREhDUHY2 IG1vZHVsZSwgdGhlbiB3ZSBjYW4gZGVjaWRlIHRoZSBwcmVzY3JpcHQgYmVoYXZpb3JzIGluIERI QyBXRywgc2luY2UgYXMgdGhlIE0mTyBkZWZpbmVkIGluIGN1cnJlbnQgc3RhbmRhcmQsIGl0IGlz IG9ubHkgYSAiaGludCIuIEJ1dCBpZiBpdCBpcyBpbiBzb21lIG90aGVyIG1vZHVsZSBpbiB0aGUg T1MsIHRoZSBESENQdjYgY2FuIGp1c3QgZG8gc29tZSBib3R0b20gbGluZSBsaWtlIHRoZSBhYm92 ZSBtZW50aW9uZWQgc3BlY2lmaWMgYmVoYXZpb3JzLg0KDQpCZXN0IHJlZ2FyZHMsDQpCaW5nDQoN ClNlZSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1kaGMtcmZjMzMxNWJp cy0wNi4gKFRoZSBjb2F1dGhvcnMgYXJlIHN0aWxsIHdvcmtpbmcgdGhyb3VnaCBvdXIgYmFja2xv ZyBvZiBhYm91dCAzMDAgY29tbWVudHMgZHVyaW5nIFdHTEMg4oCTIHdlIGhhdmUgZG9uZSBhYm91 dCA3NSUgb2YgdGhlbS4pDQoNCi0gQmVybmllDQoNCk9uIDEvMTIvMTcsIDEwOjAzIEFNLCAidjZv cHMgb24gYmVoYWxmIG9mIFRpbSBDaG93biIgPHY2b3BzLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVo YWxmIG9mIFRpbS5DaG93bkBqaXNjLmFjLnVrPiB3cm90ZToNCg0KICAgIEhpLA0KICAgIA0KICAg ID4gT24gMTEgSmFuIDIwMTcsIGF0IDE1OjM3LCBSb24gQm9uaWNhIDxyYm9uaWNhQGp1bmlwZXIu bmV0PiB3cm90ZToNCiAgICA+IA0KICAgID4gRm9sa3MsDQogICAgPiANCiAgICA+IERyYWZ0LWll dGYtdjZvcHMtZGhjcHY2LXNsYWFjLXByb2JsZW0gd2FzIGludHJvZHVjZWQgMy41IHllYXJzIGFn bywgYnV0IGhhcyBtYWRlIGxpdHRsZSBwcm9ncmVzcyBpbiB0aGUgbGFzdCB5ZWFyLiBUaGVyZWZv cmUsIGl0IGJlY29tZSBuZWNlc3NhcnkgZm9yIHRoZSBjaGFpcnMgdG8gcmVldmFsdWF0ZSB3aGV0 aGVyIHRoaXMgZHJhZnQgc2hvdWxkIGNvbnRpbnVlIHRvIGJlIGEgV0cgaXRlbS4NCiAgICA+IA0K ICAgID4gSWYgeW91IGhhdmUgYW4gb3BpbmlvbiBvbiB0aGlzIHN1YmplY3QsIHBsZWFzZSBwb3N0 IGl0IHRvIHRoZSBtYWlsaW5nIGxpc3QgYnkgMS8yNS8xNy4gT3B0aW9ucyBhcmU6DQogICAgPiAN CiAgICA+IDEpIENvbnRpbnVlIHRvIHdvcmsgb24gdGhlIGRyYWZ0IHdpdGggYW4gZXllIHRvd2Fy ZCBwdWJsaWNhdGlvbiBpbiAyMDE3DQogICAgPiAyKSBBbGxvdyB0aGUgZHJhZnQgdG8gZXhwaXJl DQogICAgDQogICAgSXTigJlzIHRyaWNreS4NCiAgICANCiAgICBJIGRvIGZpbmQgbXlzZWxmIHJl ZmVycmluZyBwZW9wbGUgdG8gdGhpcyBkb2N1bWVudCBhcyBhIHByb2JsZW0gc3RhdGVtZW50LCBm cm9tIHRpbWUgdG8gdGltZS4gIEluIHRoYXQgY29udGV4dCwgaXTigJlzIHVzZWZ1bC4gDQogICAg DQogICAgQnV0IGFzIE9sZSBzYXlzLCB3aGlsZSBhIG51bWJlciBvZiBhbWJpZ3VpdGllcyBhcmUg bm90ZWQsIHRoZXJlIGFyZSBubyDigJxmaXhlc+KAnSBwcm9wb3NlZC4gIA0KICAgIA0KICAgIElm IHRoZSBkb2N1bWVudCBpcyB0byBiZSBwdWJsaXNoZWQsIHNob3VsZCB3ZSBub3QgbWFrZSBzb21l IHJlY29tbWVuZGF0aW9ucz8NCiAgICANCiAgICBJZiB0aGUgQXBwZW5kaXggaXMgdG8gcmVtYWlu LCByZXN1bHRzIGZvciBjdXJyZW50IE9TZXMgd291bGQgYmUgdXNlZnVsLg0KICAgIA0KICAgIFRp bQ0KICAgIA0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQogICAgdjZvcHMgbWFpbGluZyBsaXN0DQogICAgdjZvcHNAaWV0Zi5vcmcNCiAgICBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQogICAgDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQp2Nm9wcyBtYWlsaW5nIGxp c3QNCnY2b3BzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3Y2b3BzDQo= From nobody Mon Jan 16 07:17:40 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A15F129554 for ; Mon, 16 Jan 2017 07:17:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 SO2bS7i4ZOUb for ; Mon, 16 Jan 2017 07:17:37 -0800 (PST) Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D2C2129547 for ; Mon, 16 Jan 2017 07:17:37 -0800 (PST) Received: by mail-ua0-x230.google.com with SMTP id y9so83633326uae.2 for ; Mon, 16 Jan 2017 07:17:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sYWwo5lwXnvtyIaQZzSx/byXG07dfWw9GUaxsbFWoiA=; b=m0k29wpcSEJqnhIlPgU8oNadAiDVWs45pnGrD3GzgM30LNDNelp1OugEdzklGc6zz5 RMW/32MoMRLEhZwjNK2fDpVK4BubHfUQzm0vnYLWiQ5dL37tG8HQ+ZgSRWmy3XN0YgbH eOGROVJyNGAZSJ9GowTWO5XH4kKbLVr1jCfcy3PDfAzaKiI8CFlrwo4UId6R2/oKeX+a 2ae22crRtlnNyvxUAQ3yy4V4gJnEPlRiicMgEM9kZbssMzw/cVC1FceyJDoL325YJSlz bAxwBXI1VcBeC6PFmUtSYQoMzfKMw6+lQpPRGPfz8eUb7ifohKdahXLmQbHVsST0es3J sTJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sYWwo5lwXnvtyIaQZzSx/byXG07dfWw9GUaxsbFWoiA=; b=n1YIZql8xVUd3egxk5zKrrc++2vfq6hKUSyxWpi9Oltl5MT/P+DB+W+swFGw9nTGj6 HOba50DsqY4dgmU2kf+9OBPDE1Tw1m2eGHifD5IWCEFcH/Ab0PBvz1sp2LJUxzCZhuO9 36K6j9gfS0+oou5xFlxrlmvye63WGPGCu9DpQ6vH80Cm0M+s9Jcdi7JZs1rIa6XpJlUk EirvsvpJ1cHDBgSWy72z0wHCxqDsT7MC3cVS9JKUbCXlSPeX/wPEPtC+Ul0ZhTlsDpht ZeVrm2V34PEqeObx6eyUUbaGj/bCCFX+GeNv+kUOa+x79Jgvi6AlBKUHAJLVeE9mM9Nu fDLw== X-Gm-Message-State: AIkVDXLd60NsdCDQx7FQtr0YFgDkVh99zQ3PlsVal4/prO+Du73h0pvUvts6hxTkYT7l8+jLOzDlKYqGfX0WweU3 X-Received: by 10.159.49.27 with SMTP id m27mr17735420uab.72.1484579856341; Mon, 16 Jan 2017 07:17:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.171.2 with HTTP; Mon, 16 Jan 2017 07:17:15 -0800 (PST) In-Reply-To: References: From: Lorenzo Colitti Date: Tue, 17 Jan 2017 00:17:15 +0900 Message-ID: To: Ron Bonica Content-Type: multipart/alternative; boundary=f403045ddf74faa14f054637ae0d Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 15:17:39 -0000 --f403045ddf74faa14f054637ae0d Content-Type: text/plain; charset=UTF-8 I'm not a fan of the document in its current form. I think the data on how various operating systems behave is useful and fits well within the charter of this working group. However, I agree with Ole that I don't think there will be any "fixes" here. I'm not even sure there is a problem to fix. Unspecified behaviour is unspecified, and as an administrator, if you want predictable behaviour then you either stick to things that are clearly stated by the standards or you educate yourself on the behaviour of the various implementations that you support. I'm not sure that having two configuration protocols that overlap for IP addresses and DNS servers is a problem in itself, either. There are lots of areas where we have multiple solutions. OSPF and ISIS, LLDP and RSVP, etc. etc. On Thu, Jan 12, 2017 at 12:37 AM, Ron Bonica wrote: > Folks, > > Draft-ietf-v6ops-dhcpv6-slaac-problem was introduced 3.5 years ago, but > has made little progress in the last year. Therefore, it become necessary > for the chairs to reevaluate whether this draft should continue to be a WG > item. > > If you have an opinion on this subject, please post it to the mailing list > by 1/25/17. Options are: > > 1) Continue to work on the draft with an eye toward publication in 2017 > 2) Allow the draft to expire > > Silence or limited response will be interpreted as a lack of interest in > the draft. > > Ron, Lee and Fred > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --f403045ddf74faa14f054637ae0d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm not a fan of the document in its current form. I t= hink the data on how various operating systems behave is useful and fits we= ll within the charter of this working group.

However, I = agree with Ole that I don't think there will be any "fixes" h= ere. I'm not even sure there is a problem to fix. Unspecified behaviour= is unspecified, and as an administrator, if you want predictable behaviour= then you either stick to things that are clearly stated by the standards o= r you educate yourself on the behaviour of the various implementations that= you support.

I'm not sure that having two con= figuration protocols that overlap for IP addresses and DNS servers is a pro= blem in itself, either. There are lots of areas where we have multiple solu= tions. OSPF and ISIS, LLDP and RSVP, etc. etc.

On Thu, Jan 12, 2017 at 12:37 AM, = Ron Bonica <rbonica@juniper.net> wrote:
Folks,

Draft-ietf-v6ops-dhcpv6-slaac-problem was introduced 3.5 years ago, bu= t has made little progress in the last year. Therefore, it become necessary= for the chairs to reevaluate whether this draft should continue to be a WG= item.

If you have an opinion on this subject, please post it to the mailing list = by 1/25/17. Options are:

1) Continue to work on the draft with an eye toward publication in 2017
2) Allow the draft to expire

Silence or limited response will be interpreted as a lack of interest in th= e draft.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 Ron, Lee and Fred


_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops

--f403045ddf74faa14f054637ae0d-- From nobody Mon Jan 16 14:31:23 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00C4A12975C for ; Mon, 16 Jan 2017 14:31:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 cexP5VJkO7U4 for ; Mon, 16 Jan 2017 14:31:20 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD247129735 for ; Mon, 16 Jan 2017 14:31:20 -0800 (PST) Received: from [192.168.3.100] (142-135-17-190.fibertel.com.ar [190.17.135.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 6E43882B51; Mon, 16 Jan 2017 23:31:17 +0100 (CET) To: Lorenzo Colitti , Ron Bonica References: From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> Date: Mon, 16 Jan 2017 19:28:33 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 22:31:22 -0000 On 01/16/2017 12:17 PM, Lorenzo Colitti wrote: > I'm not a fan of the document in its current form. I think the data on > how various operating systems behave is useful and fits well within the > charter of this working group. > > However, I agree with Ole that I don't think there will be any "fixes" > here. I'm not even sure there is a problem to fix. Unspecified behaviour > is unspecified, and as an administrator, if you want predictable > behaviour then you either stick to things that are clearly stated by the > standards or you educate yourself on the behaviour of the various > implementations that you support. Sorry, but: Isn't that the whole point of standardization? If you're deploying IPv6, you're suppose to support IPv6, not specific implementations. And if you have to learn about specific implementations, that seems to me as an indication that we're doing a por job when it comes to specs. > I'm not sure that having two configuration protocols that overlap for IP > addresses and DNS servers is a problem in itself, either. The main problem is that there is a *partial overlap* when it comes to functionality, and at times no overlap when it comes to OS support. Reality is that if you want to support *IPv6*, you have to do *both* SLAAC and DHCPv6. Otherwise, there's a major OS that you're not supporting. And that's bad. > There are lots > of areas where we have multiple solutions. OSPF and ISIS, LLDP and RSVP, > etc. etc. The analogy is not good. You're not required to do both OSPF and ISIS to get your multi-vendor network working. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Jan 16 16:36:44 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 440D91294F9 for ; Mon, 16 Jan 2017 16:36:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 xBBkJdNbp9HZ for ; Mon, 16 Jan 2017 16:36:42 -0800 (PST) Received: from mail-pg0-x242.google.com (mail-pg0-x242.google.com [IPv6:2607:f8b0:400e:c05::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F30631294BB for ; Mon, 16 Jan 2017 16:36:41 -0800 (PST) Received: by mail-pg0-x242.google.com with SMTP id 75so6437346pgf.3 for ; Mon, 16 Jan 2017 16:36:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5YOcokddPl2MagUiJwJxHqEYpSPUKsC7uKcrPehOeR4=; b=aIyrUXvhiZrzmrkdKC0tyTfq5vs8JXeqIrSzH4xM/76EOyLINwAQQlQqav2hV6gWyZ 2NKBhIIOLtpY5kNDwTTgCDspa4JAidv6EtMA+39vdGtYWgrs+/S+2G0rOANT7s94ie4l XN38oMfYlrkGehEMRD9843CI3Awi5pCMfFoLOS/FAJcYs4fvh15ExGms1sAM3IIu0Rd2 upagsxn9n0LHniW4TvhdBZ1I9ayJv3AtlpSwBfGNJe338fiQIUb4FkqD60WuZHDevr7j SYK2xSywvVI/PY8mDjGRnQXUUUd8Op5l9zExa4UqFddsubUFT/qwHLs6ywOMiDnqk31y 470A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5YOcokddPl2MagUiJwJxHqEYpSPUKsC7uKcrPehOeR4=; b=LQ7ChDFcKf/Gho1mp3PsEUNfpWXlpUPfeYGYIrKV0T4k97oDQpjIp+fUMtj/Ypl154 CNP9YruT6AGyoXli0wmDX68dLAmpInOYCltkYEEusqUIDSObJ1cR4vCRFMivS4jRaK6l AZaQnvnEQZjojI/voSqt5orHUTdrlfNsGjr+ArsKc2j3RERpYjptRUSJVXSbWccWAAnl tivefqF89mROrZKGOzK/9Ggpwjnx+MhFMjZ6XOAcfYtI1Z5+HmWghaks1STn2gCUXzjU Q/quHKrp3QDZNAn7PqzIY/kVYHySL9f08NI8tJruw4xMQZahaETO7i4AWRSLl2TIN17g c+MA== X-Gm-Message-State: AIkVDXKZwMvaHewQw/37F85Jjt5umeI2O9GN8IyvgfY8esQwNkTDrSe3an3zqulUbndKMQ== X-Received: by 10.99.204.81 with SMTP id q17mr43092963pgi.168.1484613401519; Mon, 16 Jan 2017 16:36:41 -0800 (PST) Received: from [192.168.1.15] (wsip-184-191-158-59.sd.sd.cox.net. [184.191.158.59]) by smtp.gmail.com with ESMTPSA id w125sm50293750pfb.8.2017.01.16.16.36.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Jan 2017 16:36:40 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Fred Baker In-Reply-To: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> Date: Mon, 16 Jan 2017 16:36:50 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.3259) Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 00:36:43 -0000 > On Jan 16, 2017, at 2:28 PM, Fernando Gont = wrote: >=20 > If you're deploying IPv6, you're suppose to support IPv6, not specific > implementations. And if you have to learn about specific > implementations, that seems to me as an indication that we're doing a > poor job when it comes to specs. The problem is that any real world deployment is not the deployment of a = standard, but the deployment of a set of products that claim to = implement it.=20 To understand the difference, presume that there exist 100 different = implementations, of which you select 7 to put into your network. Maybe = that's iOS, Android, MacOS, Windows, Cisco, Juniper, and = OpenSourceProject#12. Maybe there's someone else, whoever. Now, imagine = that they all claim to implement the standard, but implement some = specific feature differently and incompatibly, and in the deployed = configuration, that feature isn't in use. Maybe they all implement = SLAAC, some do DAD and some don't, and some do a retry on DAD - but = address allocation is being done using DHCP, so SLAAC isn't ever = invoked. Or only some do DHCP, but SLAAC is in use. Or whatever. The fact that the network works using N-1 features satisfies you as an = operator - your network works. You may not even notice the feature = difference, or the fact that you use a different feature that does work = is your solution for the fact that the given feature doesn't. The fact that the feature, whatever it was, was implemented differently = may be a specification issue. It may also be an issue with the reader of = the specification, or the origin of the chipset, or something else.=20 But you didn't deploy a specification. You deployed a set of products = that claimed conformance to the specification, and demonstrated it to = some degree in your testing.= From nobody Mon Jan 16 17:11:06 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65CBF129956 for ; Mon, 16 Jan 2017 17:11:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 jVoSdEbwK1zR for ; Mon, 16 Jan 2017 17:11:03 -0800 (PST) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B30612994F for ; Mon, 16 Jan 2017 17:11:03 -0800 (PST) Received: by mail-oi0-x232.google.com with SMTP id m124so75173513oif.1 for ; Mon, 16 Jan 2017 17:11:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=84b+1iwqgn/mHYBKrrXDKjsUYwHda2CXnzco57UiDHk=; b=Oho8tQuqpoqOzrCrtCeCWW/3FRBzDAZH6IhdLQPDUix8/FpDIYMINFCPJWeL/sAQkM E+odCD6PDoqR+nGelDr9YuS5C5nZZEovWbk6yTL2hT+5SrcHebA404lAWoQopBhvH96y rjmQGkaT7Tck8P0leksByaCQah/F6nFLTLbe4crv8g/qKjFB6essayQx345Yh3dPplQp 2SBPtmphyGZcEdoQVlYz9s+41fIugBXu+LeY9rWUHQgF4ozszl0qwkxWQWV1/AC7y9uv KJ6sNTbs2UWZOp9S7HSeeI1GM0gSjHAMskctahoY367OhdA/hfbwdFKHDYcWgBaIlGkj GecQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=84b+1iwqgn/mHYBKrrXDKjsUYwHda2CXnzco57UiDHk=; b=aQz/Od0w1xBT+yksgqI/MA2Wb5ie7CUhLrNvzZav4SKjshGfW0ErhL90C+vH7uEiwr zXlgs0V4uiYFJhcCwIkC0d9lZz4gnMxolKosMJ2A7e/5w6VCXmGVAryT/rxgfxhWg9ej Kq4V5umNAFj4uaCDs89l0ASDtYQYqoeLz7VFhD3hRo5mfTJRDmNbrnGqWnXJzJO8UrDH l99qALQp2aUdTEMZiVbodLAw6ID91NOqNAfRjrzNpxoaoK+wALtJJZaS7oZWzpoxIdxD sl2yx8Ctrcdzg8OHXieCXrj2cfn+sCLGgWViE4rC3jU9qncMObOs5jXL04bwJA4Rch3O 8Z3A== X-Gm-Message-State: AIkVDXIEF80f3BWlt4wbdcFPqFTiQlgvMKxl8oBE658LiAI0IEYnXiQCMlCjNz/RG7oOSjZvXl+DWaxSi+1ufg== X-Received: by 10.202.108.5 with SMTP id h5mr18864290oic.29.1484615462557; Mon, 16 Jan 2017 17:11:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.227.102 with HTTP; Mon, 16 Jan 2017 17:11:02 -0800 (PST) In-Reply-To: <6b761ce0-acb6-8e16-45c5-07fa9fa2f620@isi.edu> References: <6b761ce0-acb6-8e16-45c5-07fa9fa2f620@isi.edu> From: Hemant Singh Date: Mon, 16 Jan 2017 20:11:02 -0500 Message-ID: To: Joe Touch Content-Type: multipart/alternative; boundary=001a1142dfae461ffa05463ff904 Archived-At: Cc: v6ops list Subject: Re: [v6ops] TCP related attacks/RFC3128 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 01:11:05 -0000 --001a1142dfae461ffa05463ff904 Content-Type: text/plain; charset=UTF-8 Hi Joe, Sorry for the delayed reply - I was out sick. Please see in line below. On Thu, Jan 12, 2017 at 1:48 PM, Joe Touch wrote: > IMO, the only "attack" that exists for a firewall that can't handle 20 > byte IPv4 packets at advertised line rate is on its consumers, i.e., > they're lying about supporting IPv4 at the advertised line rate. > > As I said in the past one attack on firrwalls or router ACLs is to craft an IPv4 header which is 60 bytes. Then add 8 bytes at a portion of the TCP header. Thus receivers receiving such a packet cannot get to the SYNC TCP message type of the TCP header. The hacker is also setting the MF bit in the Flags of the IP header when such a 68 byte packet has business to be fragmented on a 1500 Ethernet MTU link. > IMO, any ACL system or firewall that claims to check for information that > might not be in the initial fragment MUST perform reassembly. Although > routers aren't supposed to do reassembly, a device that needs to inspect > upper layer protocols is no longer just a router, and is acting on behalf > of an endpoint and doing part of the endpoint's job. It thus is justified > in reassembling before acting. > > Agree. Some routers which a access concentrators such as a CMTS (Cable Modem Termination System) or a DSL BNG terminate fragmented traffic between the router and the broadband modem. Thus, these routers can certainly be made robust to fragmented packet attacks. > Wonder what the minimum size of an IPv6 packet is specified in any IPv6 > RFC? I checked the IPv6 Node requirements RFC and don't find any minimum. > > > The minimum packet size would be 40 bytes, i.e., just the IPv6 header with > no data. That could be used to trigger a device or set off an alarm; there > need not be any data for a packet to be useful. > > Sorry, I wasn't clear. I meant the minimum sized IPv6 packet that won't be dropped by the network. I would think 40 bytes plus at least 8 bytes of a TCP header would be valid? > The minimum IPv6 packet that an IPv6 network MUST be able to transit > without fragmentation is 1280, as specified in RFC2460. > > Yes, I am aware of the 1280 number. Since IPv4 nodes are dropping an IPv4 packet which is smaller than 68 bytes. I was wondering, does IPv6 have some smallest size below which packets are dropped? Is the IPv6 size in 48 bytes good or should we be smart to include the complete size of the TCP header and add 40 bytes of the IPv6 header? This is the smallest packet an IPv6 network will accept. Below this size the network drops packets. Thanks, Hemant > > > > Thanks, > > Hemant > > > > > On Wed, Jan 11, 2017 at 4:58 PM, Joe Touch wrote: > >> Hi, Hemant, >> >> On 1/11/2017 8:51 AM, Hemant Singh wrote: >> >> I was looking at RFC3128. It's not specific to v6ops, but being a RFC >> that covers TCP small fragment attacks, I thought I'd send the email. I >> also think, the IETF WG that sponsored this RFC may be closed now. >> >> I wonder who approved this document because it has basic mistakes. >> >> (a) In section 2.1, the document uses "Fragment A" and also "B" for the >> first time and does not define them anywhere. >> >> Presumably these refer to Fragment 1 and 2 as defined just above in the >> same section (end of the previous page). >> >> (b) In section 2, in relation to Fragment 3, the document says "Fragment >> offset >=2". In the IP header, the fragment offset is a multiple of 8 >> octets, and thus == 2 is incorrect. >> >> The fragment offset field is indicated as a number of 8 octet units, >> e.g., 0=0 octets, 1=8 octets, and 2=16 octets, so that is valid. That's why >> the fragment field is only 13 bits long (vs. 16 bits to indicate the length >> of an IP datagram). >> >> Please let me know if there is a current IETF WG covering such issues. >> >> INTAREA would be the relevant WG, but AFAICT you're pointing out >> something we'd probably classify as an Errata, which wouldn't need to be >> addressed by a WG. You can submit those here: >> >> https://www.rfc-editor.org/errata.php >> >> Joe >> >> >> Thanks, >> >> Hemant >> >> >> _______________________________________________ >> v6ops mailing listv6ops@ietf.orghttps://www.ietf.org/mailman/listinfo/v6ops >> >> --001a1142dfae461ffa05463ff904 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Joe,

Sorry for the delayed reply - I= was out sick.=C2=A0 Please see in line below.

On Thu, Jan 12, 2017 at 1:48 PM, Joe Touch= <t= ouch@isi.edu> wrote:


 IMO, the only "attack" that exists for a firewall that can= 9;t handle 20 byte IPv4 packets at advertised line rate is on its consumers, i.e., they're lying about supporting IPv4 at the advertised line rate.

<hs> As I said in the past one attack= on firrwalls or router ACLs is to craft an IPv4 header which is 60 bytes.= =C2=A0 Then add 8 bytes at a portion of the TCP header.=C2=A0 Thus receiver= s receiving such a packet =C2=A0cannot get to the SYNC TCP message type of = the TCP header.=C2=A0 The hacker is also setting the MF bit in the Flags of= the IP header when such a 68 byte packet has business to be fragmented on = a 1500 Ethernet MTU link.=C2=A0
=C2=A0
IMO, any ACL system or firewall that claims to check for information that might not be in the initial fragment MUST perform reassembly. Although routers aren't supposed to do reassembly, a device that needs to inspect upper layer protocols is no longer just a router, and is acting on behalf of an endpoint and doing part of the endpoint's job. It thus is justified in reassembling before acting.=

<hs> Agree.=C2=A0 Some routers= which a access concentrators such as a CMTS (Cable Modem Termination Syste= m) or a DSL BNG terminate fragmented traffic between the router and the bro= adband modem.=C2=A0 Thus, these routers can certainly be made robust to fra= gmented packet attacks. =C2=A0
Wonder what the minimum size of an IPv6 packet is specified in any IPv6 RFC?=C2=A0 I checked the IPv6 Node requirements RFC and don't find any minimum.

 The minimum packet size would be 40 bytes, i.e., just the IPv6 header with no data. That could be used to trigger a device or set off an alarm; there need not be any data for a packet to be useful.

<hs> Sorry, I wasn't clear.=C2=A0= I meant the minimum sized IPv6 packet that won't be dropped by the net= work. =C2=A0 I would think 40 bytes plus at least 8 bytes of a TCP header w= ould be valid?
=C2=A0
The minimum IPv6 packet that an IPv6 network MUST be able to transit without fragmentation is 1280, as specified in RFC2460.

<hs> Yes, I am aware of= the 1280 number. =C2=A0 Since IPv4 nodes are dropping an IPv4 packet which= is smaller than 68 bytes. I was wondering, does IPv6 have some smallest si= ze below which packets are dropped?=C2=A0 Is the IPv6 size in 48 bytes good= or should we be smart to include the complete size of the TCP header and a= dd 40 bytes of the IPv6 header?=C2=A0 This is the smallest packet an IPv6 n= etwork will accept.=C2=A0 Below this size the network drops packets.=C2=A0<= /div>
=C2=A0
Thanks,

Hemant



Thanks,

Hemant




On Wed, Jan 11, 2017 at 4:58 PM, Joe Touch <touch@isi.edu> wrote:
Hi, Hemant,
On 1/11/2017 8:51 AM, Hemant Singh wrote:
I was looking at RFC3128.=C2=A0 It's= not specific to v6ops, but being a RFC that covers TCP small fragment attacks, I thought I'd send the email.=C2=A0 I also think, the IETF WG that sponsored this RFC may be closed now.=C2=A0

I wonder who approved this document because it has basic mistakes.

(a) In section 2.1, the document uses "Fragme= nt A" and also "B" for the first time and= does not define them anywhere.
 Presumably these refer to Fragment 1 and 2 as defined just above in the same section (end of the previous page).

(b) In section 2, in relation to Fragment 3, the document says "Fragment offset >=3D2"= ;.=C2=A0 In the IP header, the fragment offset is a multiple of 8 octets, and thus =3D=3D 2 is incorrect.
 The fragment offset field is indicated as a number of 8 octet units, e.g., 0=3D0 octets, 1=3D8 octets, and 2=3D1= 6 octets, so that is valid. That's why the fragment field i= s only 13 bits long (vs. 16 bits to indicate the length of an IP datagram).

Please let me know if there is a current IETF WG covering such issues.
 INTAREA would be the relevant WG, but AFAICT you're pointing out something we'd probably classify = as an Errata, which wouldn't need to be addressed by a WG. You can submit those here:

https://www.rfc-editor.org/errata.php

Joe


Thanks,

Hemant


_______________________________________________
v6ops mailing list
v6ops@ietf.org
=
https://www.ietf.org/mailman/listinfo/v6ops
=20

--001a1142dfae461ffa05463ff904-- From nobody Mon Jan 16 17:23:49 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45DDE12995B for ; Mon, 16 Jan 2017 17:23:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 i-RJB9kNvRpR for ; Mon, 16 Jan 2017 17:23:45 -0800 (PST) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82AF8129959 for ; Mon, 16 Jan 2017 17:23:45 -0800 (PST) Received: by mail-ua0-x22e.google.com with SMTP id y9so93320727uae.2 for ; Mon, 16 Jan 2017 17:23:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=G98X2lkvQ0sJ8ASd73TrzshKYCsBO3kZ6cACgqmJA0E=; b=WzMtPVLHRVoqhy7DIQ4bN1GYffQkIoYRuNE7m569fRCeQVclid/hbSwg52J58muLY5 6iVQfy57NUH9z9QvPhlAqcjtb6sQurpNefx/qEcK3vOr3YW3FbUfx/TQAwrfR3O5mfDh 4Hbmg9w/eGWjvq7Q8sjNtn9eKEObUYJ1eBbn5GY2uK8M/vsjx/ejIM5h6JX5B5Sjha2E X/8SApQ0AqVftUL5Nm9WGHAJpjzq2bDaPX/2VEF1Vl/oND5aA7yi6elyA5LymovGRfJ9 vnvb3I1aVkcoZmopCW3v4BA2WiMpfvmqTRAQSpUMxpDM1YPJ4yCf1xR6OiFGRc+d5WmF AMIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=G98X2lkvQ0sJ8ASd73TrzshKYCsBO3kZ6cACgqmJA0E=; b=XrZuOg8gPqRtsBoJNETcQNcnwOW2MTWa4vRVHH+3e8nrEish9SPLQNO9KgRZ8Zvc/x Cf/NOjVzcQTX3DrsIF52DyMmdcdvuUWbpuFxYfUH9pefQzjKtwdPNcE5JbeYYMCgteg/ cwz6Wnx9IuuCrt7hinxhdytKFNgKLsl8MQ0pYxh2FWe84snmF9tLs7cZVlDzm5q56Qy0 isOSDb3nKr7cmYnFVyZIGcr+ZRKVpvMGUoUf2cXNJVe0SGqFj04aOzNDA107l3HATajP +BEpub04tRV5IAi/na+BPxsEXHHoP1QsJMnf3EGAvukjrQoIFA6kiMMnSxiXmI7WfnV6 YZkg== X-Gm-Message-State: AIkVDXL3PsujDYA4qSZrPq/nGTHX3i0EVkF1xKmhP+cV/t/DzoGZxJnvARGA9jmDDRcyFIWynOhC0yvyCpbuM2Oi X-Received: by 10.159.49.27 with SMTP id m27mr19034703uab.72.1484616224480; Mon, 16 Jan 2017 17:23:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.171.2 with HTTP; Mon, 16 Jan 2017 17:23:23 -0800 (PST) In-Reply-To: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> From: Lorenzo Colitti Date: Tue, 17 Jan 2017 10:23:23 +0900 Message-ID: To: Fernando Gont Content-Type: multipart/alternative; boundary=f403045ddf74b065b90546402621 Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 01:23:47 -0000 --f403045ddf74b065b90546402621 Content-Type: text/plain; charset=UTF-8 On Tue, Jan 17, 2017 at 7:28 AM, Fernando Gont wrote: > Sorry, but: Isn't that the whole point of standardization? > > If you're deploying IPv6, you're suppose to support IPv6, not specific > implementations. And if you have to learn about specific > implementations, that seems to me as an indication that we're doing a > por job when it comes to specs. > Fred answered this very well. Reality is that if you want to support *IPv6*, you have to do *both* > SLAAC and DHCPv6. Otherwise, there's a major OS that you're not > supporting. And that's bad. > I disagree. Products already have to support multiple protocols at the same time. If you want to support wifi you might have to support all of WEP, WPA PSK and WPA enterprise. If you want to offer access to the Internet you have to support IPv4 and IPv6. And so on. The analogy is not good. You're not required to do both OSPF and ISIS to > get your multi-vendor network working. That's true only if all your chosen vendors support your chosen protocol. --f403045ddf74b065b90546402621 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Jan 17, 2017 at 7:28 AM, Fernando Gont <fgont@si6networks.com&= gt; wrote:
Sorry, but: Isn't t= hat the whole point of standardization?

If you're deploying IPv6, you're suppose to support IPv6, not speci= fic
implementations. And if you have to learn about specific
implementations, that seems to me as an indication that we're doing a por job when it comes to specs.

Fred an= swered this very well.

R= eality is that if you want to support *IPv6*, you have to do *both*
SLAAC and DHCPv6. Otherwise, there's a major OS that you're not
supporting. And that's bad.

I disag= ree. Products already have to support multiple protocols at the same time. = If you want to support wifi you might have to support all of WEP, WPA PSK a= nd WPA enterprise. If you want to offer access to the Internet you have to = support IPv4 and IPv6. And so on.

The analogy is not good. You're not required to do both OSPF = and ISIS to
get your multi-vendor network working.

That= 's true only if all your chosen vendors support your chosen protocol.
--f403045ddf74b065b90546402621-- From nobody Mon Jan 16 17:51:01 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73A4112995F for ; Mon, 16 Jan 2017 17:50:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.099 X-Spam-Level: X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=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 ubaFfgaxne32 for ; Mon, 16 Jan 2017 17:50:57 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43EE0129929 for ; Mon, 16 Jan 2017 17:50:57 -0800 (PST) Received: from mb-3.local ([IPv6:2601:647:4201:9e61:28fe:64ab:9f0b:9580]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id v0H1oqpF007673 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 17 Jan 2017 01:50:54 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host [IPv6:2601:647:4201:9e61:28fe:64ab:9f0b:9580] claimed to be mb-3.local To: Lorenzo Colitti , Fernando Gont References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> From: joel jaeggli Message-ID: Date: Mon, 16 Jan 2017 17:50:51 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:50.0) Gecko/20100101 Thunderbird/50.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="W2Ud4ux2GwB5GCQ0xKDp74m3IurKsEnFA" Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 01:50:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --W2Ud4ux2GwB5GCQ0xKDp74m3IurKsEnFA Content-Type: multipart/mixed; boundary="q6QJpPKFex1ukHv6T7hU3gaRmErrd5jds"; protected-headers="v1" From: joel jaeggli To: Lorenzo Colitti , Fernando Gont Cc: IPv6 Ops WG Message-ID: Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> In-Reply-To: --q6QJpPKFex1ukHv6T7hU3gaRmErrd5jds Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 1/16/17 5:23 PM, Lorenzo Colitti wrote: > On Tue, Jan 17, 2017 at 7:28 AM, Fernando Gont > wrote: >=20 > Sorry, but: Isn't that the whole point of standardization? >=20 > If you're deploying IPv6, you're suppose to support IPv6, not speci= fic > implementations. And if you have to learn about specific > implementations, that seems to me as an indication that we're doing= a > por job when it comes to specs. >=20 >=20 > Fred answered this very well. >=20 > Reality is that if you want to support *IPv6*, you have to do *both= * > SLAAC and DHCPv6. Otherwise, there's a major OS that you're not > supporting. And that's bad. >=20 >=20 > I disagree. Products already have to support multiple protocols at the > same time. If you want to support wifi you might have to support all of= > WEP, WPA PSK and WPA enterprise. If you want to offer access to the > Internet you have to support IPv4 and IPv6. And so on. You might also have to support two bands and 5 modulation schemes in the interest of backwards compability. Or you might selectively elide the ones that are only required for legacy device support or which are so new that only a limited nuber of devices support them, in favor of a common subset supported by current modern devices. > The analogy is not good. You're not required to do both OSPF and IS= IS to > get your multi-vendor network working. >=20 >=20 > That's true only if all your chosen vendors support your chosen protoco= l. >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 --q6QJpPKFex1ukHv6T7hU3gaRmErrd5jds-- --W2Ud4ux2GwB5GCQ0xKDp74m3IurKsEnFA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlh9eHwACgkQ8AA1q7Z/VrJMNgCdEMJ8y3b2pxeBtCgr2JE9yAnd Rf4AoIOBb+auP1IbotAD+qv+QflWXLvF =I1cX -----END PGP SIGNATURE----- --W2Ud4ux2GwB5GCQ0xKDp74m3IurKsEnFA-- From nobody Mon Jan 16 19:13:44 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81ADB12997D for ; Mon, 16 Jan 2017 19:13:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.42 X-Spam-Level: X-Spam-Status: No, score=-7.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 ZtMUnpYtWrXm for ; Mon, 16 Jan 2017 19:13:41 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 520711294B8 for ; Mon, 16 Jan 2017 19:13:40 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CYZ10718; Tue, 17 Jan 2017 03:13:37 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 17 Jan 2017 03:13:36 +0000 Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Tue, 17 Jan 2017 11:13:31 +0800 From: "Liubing (Leo)" To: IPv6 Ops WG Thread-Topic: Possible consensus of dhcpv6-slaac-problem draft Thread-Index: AQHScG+u/Kql0lmeGEKlzbtVJBMOtw== Date: Tue, 17 Jan 2017 03:13:31 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45C2E981DF@nkgeml514-mbx.china.huawei.com> References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.191.175] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.587D8BE2.003E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 9add52653f1aa56d3124d5c5f15cfd5e Archived-At: Cc: "v6ops-chairs@tools.ietf.org" Subject: [v6ops] Possible consensus of dhcpv6-slaac-problem draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 03:13:43 -0000 Hi Dear all, Thanks for all your comments. While reading through the mails, my impression is that the WG seems still h= ave some interest of this draft. Although there is still controversy, I thi= nk we also have a chance to get consensus. So, my proposed next step of the draft is: 1) Re-phrase the document to make it more like a report and caution of curr= ent divergent behaviors, rather than stating "problems".=20 I think most of the texts could be kept, but with a different tone. The div= ergence analysis and the OSes behaviors are objective; whether it is a "pro= blem" is subjective. In this document, we just keep a neutral position.=20 In this sense, I would request to change the draft name as e.g. "draft-ietf= -v6ops-dhcpv6-slaac-implementation-divergence" If in the future we all agree it is "Problem", then we can make a new draft= discussing the fixes. 2) Update the test to include the latest versions of main stream OSes, and = also include another OpenSource OS other than Linux (e.g. FreeBSD). I will do step 1) first within this week, and ask the WG for review. If we = can get consensus, then we'll do step 2). Does it sound ok? Thanks. Best regards, Bing From nobody Mon Jan 16 23:22:58 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0257D12940B for ; Mon, 16 Jan 2017 23:22:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.309 X-Spam-Level: X-Spam-Status: No, score=-0.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=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 SYjLQw5oZ17r for ; Mon, 16 Jan 2017 23:22:55 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75B761293FD for ; Mon, 16 Jan 2017 23:22:55 -0800 (PST) Received: from [192.168.3.101] (142-135-17-190.fibertel.com.ar [190.17.135.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id E49A183690; Tue, 17 Jan 2017 08:22:50 +0100 (CET) To: Fred Baker References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> Date: Tue, 17 Jan 2017 00:15:39 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 07:22:57 -0000 On 01/16/2017 09:36 PM, Fred Baker wrote: > >> On Jan 16, 2017, at 2:28 PM, Fernando Gont >> wrote: >> >> If you're deploying IPv6, you're suppose to support IPv6, not >> specific implementations. And if you have to learn about specific >> implementations, that seems to me as an indication that we're doing >> a poor job when it comes to specs. > > > > The problem is that any real world deployment is not the deployment > of a standard, but the deployment of a set of products that claim to > implement it. Of course. Now, if product A says it supports IPv6, and Network A says it supports IPv6, I expect to be able to use product A in Network B. If both can truly say they support IPv6, but they cannot interoperate (*), then something is missing in the spec. (*) in this case, I expect my host to, at the very least, be able to learn a default route and caching DNS server, and automatically configure an IPv6 address. > To understand the difference, presume that there exist 100 different > implementations, of which you select 7 to put into your network. > Maybe that's iOS, Android, MacOS, Windows, Cisco, Juniper, and > OpenSourceProject#12. Maybe there's someone else, whoever. Now, > imagine that they all claim to implement the standard, but implement > some specific feature differently and incompatibly, and in the > deployed configuration, that feature isn't in use. I expect the spec to specify what are the features that are required to get "(*)". And if in order to get "(*)" I now need to deploy two different protocols, that most likely need to be configured in different places, with different outcomes based on e.g. implementation, I think that's bad (particularly when it was previously possible to get essentially the same thing with a single protocol). This increases complexity & attack surface, etc. [...] > The fact that the network works using N-1 features satisfies you as > an operator - your network works. That's the point: If I have to deploy two different protocols because need both of them to support the three major OSes, I don't think that's good. And If I actually have to figure that out by myself, that's worse. Frankly, I cannot quite understand the discussion here, particularly when this group produced e.g. RFC6540 -- but I might be missing something. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Jan 17 06:04:33 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59B411293FD for ; Tue, 17 Jan 2017 06:04:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 QVhLpR_L_sfY for ; Tue, 17 Jan 2017 06:04:29 -0800 (PST) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95796127076 for ; Tue, 17 Jan 2017 06:04:29 -0800 (PST) Received: by mail-qt0-x232.google.com with SMTP id x49so158192506qtc.2 for ; Tue, 17 Jan 2017 06:04:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Ty35zPcP828JrPDEkSv+lc028ZcXleR5xatUGmN6wis=; b=E4ZLOJgA2eKsLt6TBnQ+hVHHc8mbW7SwNZZB7yEmq70tmH83j4tM9x4osIR1ktr/JY dPnEs+6Tg/2CXSaM0GdqXTsQ/cg+Zn+4uwJF4RQVfR2Yk65kz6M7hvsc6Ww8oeqEwy6Z WiTZ9z53cbjr7kfDkoosHV5fFpi5m72N1w/WrFRdWWC+M6NAM1/pp8oLJnaOGffiwdnv 9HhIBy9biR1J7shubWRuks91ghyg4ACB0sUtJP+oMri+FCJPKu9A/ZllYlhn49fLq/Ox PPY1kkjdfjvW7/WtbTgVF/2NzfEETMS+YBQq64WOXCHhWMwK7UbIVEEHCDLRGN58MT/9 8xSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Ty35zPcP828JrPDEkSv+lc028ZcXleR5xatUGmN6wis=; b=af+pKSiUJfCzGtvgcE+0WC/85eEebz9IUAG1YWPuJ9arNA87MEwLB+cfiSHzk5u2Kk +7HzmU7ag7fNL32jqnuk0s8zTSJT4SnVOxUoc04ZN0KMurQaYYI2arVfRhkMrh1gUxi+ 8YQk2N6Kr0xQ/61KrsEbuL1V/jq8vqdi/nYR8a0GIVD9fbv1PuW+frFFz2eOigY0Thx6 gNleJmyKP7DI48iV25kol1pKef3K5subsi8+qQdEPrDxlibIC8lVj214sV5ySDDnXi7W 2HSqVfrvEHSQr2mNQh04KTk6yJEZQbiVAENWlQ7vUZ+QHFyZBl+QvsMgBYpy0rd2889Y IPUQ== X-Gm-Message-State: AIkVDXLhXw/VUG+frKQb9qE9Te7dW6nmOgysj8Fwjcp6fweMzQ+RCsomPxv8Z27afBnTHQ== X-Received: by 10.55.22.219 with SMTP id 88mr34592723qkw.283.1484661868306; Tue, 17 Jan 2017 06:04:28 -0800 (PST) Received: from [10.0.20.229] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id l51sm13822504qtb.13.2017.01.17.06.04.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Jan 2017 06:04:25 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ted Lemon In-Reply-To: <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> Date: Tue, 17 Jan 2017 09:04:14 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <965F57AB-1807-4480-9025-520D587A612A@fugue.com> References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.3259) Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 14:04:31 -0000 Fernando, another way to approach the question would be to ask, if there = is a single protocol that is required (which there is), and that = protocol can provide all the information that a host needs to = interoperate on the network, is implementation of another protocol that = duplicates some, but not all, of that functionality actually sensible? IOW, you seem to be focusing on the failure of some IPv6 stacks to = implement one protocol, but not on the failure of other IPv6 stacks to = fully implement one of the protocols they support. If your problem is = that you want it to be the case that there is a minimum set of = functionality that can be deployed on a particular network in order for = all hosts to interoperate, then it doesn't matter which of these = problems gets solved, as long as one or the other is solved. And in = that case, I would expect to see you arguing for both, hoping to win = one. But I only see you arguing for one solution to this problem, and it is = the one that requires hosts to implement two protocols, rather than the = one that requires hosts to fully implement one protocol. Can you say = why you prefer the two-protocol solution? From nobody Tue Jan 17 07:01:52 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5E5D1294C8 for ; Tue, 17 Jan 2017 07:01:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 urPuzmRGyCAR for ; Tue, 17 Jan 2017 07:01:48 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74B7412946E for ; Tue, 17 Jan 2017 07:01:48 -0800 (PST) Received: from [192.168.3.101] (142-135-17-190.fibertel.com.ar [190.17.135.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id E2A94836A2; Tue, 17 Jan 2017 16:01:44 +0100 (CET) To: Ted Lemon References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> Date: Tue, 17 Jan 2017 11:58:48 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <965F57AB-1807-4480-9025-520D587A612A@fugue.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 15:01:51 -0000 Hi, Ted, On 01/17/2017 11:04 AM, Ted Lemon wrote: > Fernando, another way to approach the question would be to ask, if > there is a single protocol that is required (which there is), and > that protocol can provide all the information that a host needs to > interoperate on the network, is implementation of another protocol > that duplicates some, but not all, of that functionality actually > sensible? Phrased that way, the answer is obviously "No". However, 1) RDNSS was standardized not such a long time ago (should double-check, but..) after pro-dhcpv6 vendors had already implemented DHCPv6. 2) At this point it is probably too late to answer the question, but: Not sure it buys much to the guy deploying v6 "just to get more addresses" to have to learn a whole different way of doing things (slaac). In that sense, I understand those folks meaning to stick to slaac. > IOW, you seem to be focusing on the failure of some IPv6 stacks to > implement one protocol, but not on the failure of other IPv6 stacks > to fully implement one of the protocols they support. To make my point clear: I don't care about what's the winner in "slaac vs. v6", but I'm just concerned about having to deploy both because I cannot support the two/three major OSes with a single protocol. > If your > problem is that you want it to be the case that there is a minimum > set of functionality that can be deployed on a particular network in > order for all hosts to interoperate, then it doesn't matter which of > these problems gets solved, as long as one or the other is solved. Exactly. > But I only see you arguing for one solution to this problem, and it > is the one that requires hosts to implement two protocols, rather > than the one that requires hosts to fully implement one protocol. > Can you say why you prefer the two-protocol solution? I don't. I don't care about what specific protocol I can use, as long as I can use one to support all my hosts (e.g., having Windows and others support RDNSS off-the-shelf works for me.. and if there's a way to help things in that direction (make such support a MUST), I'm game). That said, I have also heard complaints from quite a few ISPs deploying IPv6 regarding why they can't just do dhcp, and have to do something else to essentially get the same thing as in IPv4 (they only wanted longer addresses, not learn new fancy stuff). And in that sense, their concerns seem understandable, too. So in that respect, at this point, rather than fighting over a specific way to configure hosts (with the current outcome of "you have to do both!"), I'd probably try to make things easier/simpler for folks deploying v6, give them the two protocols as fully-working *options*, and let them decide by themselves whatever works better for them. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Jan 17 07:38:42 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D57E12943E for ; Tue, 17 Jan 2017 07:38:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 3DAznIevGECa for ; Tue, 17 Jan 2017 07:38:38 -0800 (PST) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC4231293F8 for ; Tue, 17 Jan 2017 07:38:38 -0800 (PST) Received: by mail-qt0-x236.google.com with SMTP id x49so162873241qtc.2 for ; Tue, 17 Jan 2017 07:38:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=24DYUOh1VZ2UuUmnF/PPFzMMFTYjnfulm3E+ZTqM6tU=; b=skYAUtXeETgE8DdVl0e8GNZKBMMIjgMS2Mq1RNrrTQVP44JFsJqkteydltStu98N1R d8zyJeEnCXAros/zRJGvsz2Zn3h0RWXQjeh0FLrvjqU9G6NGGFzPf2R5w+RintrvzPR3 SZnNb3tKV7fWh5OZJkrMVdGlCftsCTBKHYLr77IdhYpAUpiXmK+AOtd2OsAJBF85YgwC 7uDIJElJmIRnQI2gybOOKOkvkTJtJM5yjlkVENfmp9Hceyl841gRt08s8JRXzoO1VHAx sOuLKfAciKPBYFuWjMZHLLa1FKEbZiDaTu6oSEoGE9M/l6A8K/WogNVbEhd7rFwbYDgT Enng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=24DYUOh1VZ2UuUmnF/PPFzMMFTYjnfulm3E+ZTqM6tU=; b=aKI5gmxUC0F1hp7TyHg2EnQRboiBQTRDZ2Rp9eS9h9UoNoZGHRRUK4w13eAfXoQYll ZqGPbIzcYN3LHDF0PmukCoR5WzRzkJv4Si6BKHx2yavpON7dzrCq6IbLkd+b/6zFnKJX QoyPIPKorP+t4TL03/RKegRu2LG4wWDZuF015wjondTeUu4yqkBLepaGHKGeuhljMqse L8lCAyY3owML4qYf6OaAXqIVHKFISXdPskpc9/mzb+zM4comrAZDRiqfyGYx2cDHOKI3 FVix2JqGyTBil8BVi1tF0FdRYTqjtMO5ZjjnsoBDMuBPOuU7Am9ixgXzbSJ5J5++poDn YdHg== X-Gm-Message-State: AIkVDXLtlC4f6dzTFXNtnZfFqo1p2p38CbvVzEmIztYqwK4eJpeeTJKfF80sXGXbtcRtOQ== X-Received: by 10.200.48.110 with SMTP id g43mr33736522qte.277.1484667517590; Tue, 17 Jan 2017 07:38:37 -0800 (PST) Received: from [10.0.20.229] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id s71sm19055803qkl.22.2017.01.17.07.38.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Jan 2017 07:38:36 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ted Lemon In-Reply-To: <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> Date: Tue, 17 Jan 2017 10:38:35 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.3259) Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 15:38:40 -0000 On Jan 17, 2017, at 9:58 AM, Fernando Gont = wrote: > 1) RDNSS was standardized not such a long time ago (should = double-check, > but..) after pro-dhcpv6 vendors had already implemented DHCPv6. It's been a little over six years, and there have been quite a few = Windows releases since then, so we can I think safely conclude that if a = vendor has not implemented it, it's not because they didn't have an = opportunity to do so. > 2) At this point it is probably too late to answer the question, but: > Not sure it buys much to the guy deploying v6 "just to get more > addresses" to have to learn a whole different way of doing things > (slaac). In that sense, I understand those folks meaning to stick to = slaac. This may or may not be true, but doesn't seem relevant to the draft = being discussed. > I don't. I don't care about what specific protocol I can use, as long = as > I can use one to support all my hosts (e.g., having Windows and others > support RDNSS off-the-shelf works for me.. and if there's a way to = help > things in that direction (make such support a MUST), I'm game). Well, right now it's RECOMMENDED in RFC 6434. I suppose we could = update the RFC to say REQUIRED, but it's hard to understand why an = implementation would choose to ignore this recommendation if there = weren't some specific reason for doing so, so it might be worth asking = the vendors that don't implement RDNSS why they have chosen not to. > That said, I have also heard complaints from quite a few ISPs = deploying > IPv6 regarding why they can't just do dhcp, and have to do something > else to essentially get the same thing as in IPv4 (they only wanted > longer addresses, not learn new fancy stuff). And in that sense, their > concerns seem understandable, too. So in that respect, at this point, > rather than fighting over a specific way to configure hosts (with the > current outcome of "you have to do both!"), I'd probably try to make > things easier/simpler for folks deploying v6, give them the two > protocols as fully-working *options*, and let them decide by = themselves > whatever works better for them. Here I do not believe you are talking about RDNSS. It sounds like you = are saying "why can't some nodes simply _not_ implement SLAAC." This = is very far afield for a discussion of this particular document. If = you want to propose such a thing, you might want to start a separate = discussion.= From nobody Tue Jan 17 08:03:15 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50D2812954B for ; Tue, 17 Jan 2017 08:03:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.4 X-Spam-Level: X-Spam-Status: No, score=-7.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 6MPLffrBK-QQ for ; Tue, 17 Jan 2017 08:03:07 -0800 (PST) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with ESMTP id 741CC1294C6 for ; Tue, 17 Jan 2017 08:03:07 -0800 (PST) Received: from localhost (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by bizet.nethelp.no (Postfix) with ESMTP id E2063E6065; Tue, 17 Jan 2017 17:03:05 +0100 (CET) Date: Tue, 17 Jan 2017 17:03:05 +0100 (CET) Message-Id: <20170117.170305.74705723.sthaug@nethelp.no> To: fgont@si6networks.com From: sthaug@nethelp.no In-Reply-To: <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> References: <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 16:03:09 -0000 > 1) RDNSS was standardized not such a long time ago (should double-check, > but..) after pro-dhcpv6 vendors had already implemented DHCPv6. We recently asked Huawei about RDNSS for their NE40 series routers. The answer we got was basically "Not implemented, no specific plans to do so." DHCPv6 is a must for us. Steinar Haug, AS2116 From nobody Tue Jan 17 08:53:17 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C66B129588 for ; Tue, 17 Jan 2017 08:53:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 6WE2u-Xd6VD5 for ; Tue, 17 Jan 2017 08:53:15 -0800 (PST) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D6E512958A for ; Tue, 17 Jan 2017 08:53:15 -0800 (PST) Received: by mail-ua0-x22e.google.com with SMTP id y9so107542499uae.2 for ; Tue, 17 Jan 2017 08:53:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=I1+91w3mQHfjbxABsY6iEpkPknjsIUFfiSPtuAQa/pM=; b=hIbNM0b7R/kD5wBeSVnBf8TqGwhsiDFozbwocGZRyUNHXZcVG69jQ9wxSqiojLFjRY aFahtHAcqtAKVEp2llfLnat4WfiAsN2pGfcQFQ/blvGKo7k2m9YstEqFEpnDMbu7tbe9 TduESojIkSwFjmmvIe3MP9JdyqkViu7gYe5OUdgdJf5Dc5DxXXyrcXQQJq5Z/NdWAGqv puRw0d3JOlPhce908PPCt09TmTEB3QDNGqdp1tnF6s+kr0L5N6DIVgy34SoW8sTdf2vm cXu8GTyLdfLyD1ZQoS5/hPmiaaMlR+jZ+rKR66+GuLjB2eMSnbq69MRi8XkS3E1eOEsZ NORQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=I1+91w3mQHfjbxABsY6iEpkPknjsIUFfiSPtuAQa/pM=; b=pquvjGExjVU+SFJ69vzJ79Cny2h4/8SnIvP02VETLGpPNxf8p36A7N7jWC7sOIj13z jgGLHmc7V+wK97BnBlQrPAr8/e9YZSgI1/VeTHtXWB+ib9dS47IHwCtPMPBgySUo68A+ iPj3Ri0tPOIeXnSWKp8ByFpqVpD0OBfHI/pjD241mUhXXBh3O5Y7FucWoHra5t3lRl27 r+h7Crozm3jGlEV98puxrbtHFpKLrSZOvFmWiuRgUozGEHxZhPgGThz4Quo7eHYzsRVN B63yV/1BEXAgviaK9r6LUBDOfxM73YxZJKCO+E2hxgxOMyfNR+7A/MmNh0Rcp/QcFyCQ ASnw== X-Gm-Message-State: AIkVDXL+9ib1JBPRjuCB2E15yFU1T8SRo8fRpggHSx6bVTfUVkSWeTYoOtQkKS2TDNZPkXt/vyhMCAN+glhhyQ== X-Received: by 10.159.49.92 with SMTP id n28mr18108398uab.95.1484671993798; Tue, 17 Jan 2017 08:53:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.2.235 with HTTP; Tue, 17 Jan 2017 08:52:43 -0800 (PST) In-Reply-To: <20170117.170305.74705723.sthaug@nethelp.no> References: <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <20170117.170305.74705723.sthaug@nethelp.no> From: Mark Smith Date: Wed, 18 Jan 2017 03:52:43 +1100 Message-ID: To: sthaug@nethelp.no Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Fernando Gont , v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 16:53:16 -0000 On 18 January 2017 at 03:03, wrote: >> 1) RDNSS was standardized not such a long time ago (should double-check, >> but..) after pro-dhcpv6 vendors had already implemented DHCPv6. > > We recently asked Huawei about RDNSS for their NE40 series routers. > The answer we got was basically "Not implemented, no specific plans to > do so." > > DHCPv6 is a must for us. > I don't really understand why there seems to be a belief that DNS is the only host parameter that needs to have automated configuration, and therefore RDNSS is the only thing that is needed. Hosts have other parameters that may need to be set such as NTP source, timezone etc. RDNSS has other limitations, such as not being able to do or easily do individual host specific DNS settings, and not being able to have a centralised parameter source - if you want to change the DNS value provided by RDNSS by 10000 routers, you have no choice by to change the configuration of 10000 routers. DHCPv6 is more capable, flexible and general purpose. (I'm not making the assertion that if you use DHCPv6 then you must use it for addresses. That's a choice available, however I would use SLAAC for addresses and stateless DHCPv6 for the other upper layer host parameters.) Regards, Mark. > Steinar Haug, AS2116 > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Jan 17 08:56:59 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D60D129590 for ; Tue, 17 Jan 2017 08:56:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.098 X-Spam-Level: X-Spam-Status: No, score=-10.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=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 KE3RyA6WFJEq for ; Tue, 17 Jan 2017 08:56:56 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34EA812958B for ; Tue, 17 Jan 2017 08:56:56 -0800 (PST) Received: from [192.168.1.189] (cpe-172-250-251-17.socal.res.rr.com [172.250.251.17]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v0HGuSeP003566 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 17 Jan 2017 08:56:30 -0800 (PST) To: Hemant Singh References: <6b761ce0-acb6-8e16-45c5-07fa9fa2f620@isi.edu> From: Joe Touch Message-ID: Date: Tue, 17 Jan 2017 08:56:28 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------DAA1DB8F6F9FE7BFA00846D7" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: v6ops list Subject: Re: [v6ops] TCP related attacks/RFC3128 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 16:56:58 -0000 This is a multi-part message in MIME format. --------------DAA1DB8F6F9FE7BFA00846D7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi, Hemant, On 1/16/2017 5:11 PM, Hemant Singh wrote: > Hi Joe, > > Sorry for the delayed reply - I was out sick. Please see in line below. > > On Thu, Jan 12, 2017 at 1:48 PM, Joe Touch > wrote: > > > IMO, the only "attack" that exists for a firewall that can't > handle 20 byte IPv4 packets at advertised line rate is on its > consumers, i.e., they're lying about supporting IPv4 at the > advertised line rate. > > As I said in the past one attack on firrwalls or router ACLs is > to craft an IPv4 header which is 60 bytes. Then add 8 bytes at a > portion of the TCP header. If you are talking about a single IP packet, that should not be considered an attack. If you're talking about fragments, then you need to describe the case more clearly. IMO, a firewall always needs to reassemble fragments. > Thus receivers receiving such a packet cannot get to the SYNC TCP > message type of the TCP header. The hacker is also setting the MF bit > in the Flags of the IP header when such a 68 byte packet has business > to be fragmented on a 1500 Ethernet MTU link. Remember that an IPv4 packet with DF=0 can be fragmented anywhere in the network and both IPv4 and IPv6 can be fragmented at the source. IPv4 requires that a 68 byte packet can traverse the net without fragmentation but there are no rules that prohibit smaller packets or fragments. E.g., if you are sending a 100-byte packet and it needs to be fragmented down to 68 bytes, it's entirely valid to make the first fragment as 32 bytes. Anything longer than the IP header ought is defined as valid. > > > IMO, any ACL system or firewall that claims to check for > information that might not be in the initial fragment MUST perform > reassembly. Although routers aren't supposed to do reassembly, a > device that needs to inspect upper layer protocols is no longer > just a router, and is acting on behalf of an endpoint and doing > part of the endpoint's job. It thus is justified in reassembling > before acting. > > Agree. Some routers which a access concentrators such as a CMTS > (Cable Modem Termination System) or a DSL BNG terminate fragmented > traffic between the router and the broadband modem. Thus, these > routers can certainly be made robust to fragmented packet attacks. > >> Wonder what the minimum size of an IPv6 packet is specified in >> any IPv6 RFC? I checked the IPv6 Node requirements RFC and don't >> find any minimum. > > The minimum packet size would be 40 bytes, i.e., just the IPv6 > header with no data. That could be used to trigger a device or set > off an alarm; there need not be any data for a packet to be useful. > > Sorry, I wasn't clear. I meant the minimum sized IPv6 packet > that won't be dropped by the network. I would think 40 bytes plus at > least 8 bytes of a TCP header would be valid? The *minimum* for traffic is 40 bytes, the size of the smallest IPv6 header. As to fragments, the same rule applies as for IPv6. Note - if a fragment - initial or otherwise - contains 0 bytes of payload, that might be considered invalid because it prevents reassembly from "making forward progress"; strictly, it's allowed, but it doesn't make sense to send such a message. However, both protocols allow it AFAICT. > > > The minimum IPv6 packet that an IPv6 network MUST be able to > transit without fragmentation is 1280, as specified in RFC2460. > > Yes, I am aware of the 1280 number. Since IPv4 nodes are > dropping an IPv4 packet which is smaller than 68 bytes. That is broken behavior. The smallest valid IPv4 packet is 20 bytes, and the smallest that would still make progress in reassembly is 28; for IPv6 it would be 56 (40 for the IP header, 8 for the fragmentation extension, and 8 for the smallest fragment. There's absolutely no rule that all IPv6 fragments must be larger than 68 except for the last fragment. Remember as well that the fragments don't always "break" in even pieces because a packet might traverse links with different MTUs. E.g., consider traversing links with MTUs of 95 then 90: 200 (i.e., 180d + 20h) -> 92 (72d+20h), 92 (72d+20h), 36 (16d+20h) -> 84 (64d+20h), 28 (8d+20h), 84, 28, 36 I.e., small fragments can be generated by a succession of hops that have decreasing MTUs. > I was wondering, does IPv6 have some smallest size below which packets > are dropped? An IPv6 link can't drop anything that has at least an IPv6 header. If you want to say "it's safe to drop fragments that don't make sense", then anything with a fragment offset extension should be at least 56 bytes (48 would be just IP + FH, and that's not enough to make progress). But you have to look at the header to figure that out - otherwise, 40 bytes without a fragment header is still valid. > Is the IPv6 size in 48 bytes good or should we be smart to include the > complete size of the TCP header and add 40 bytes of the IPv6 header? > This is the smallest packet an IPv6 network will accept. Below this > size the network drops packets. IPv4 with MF = 1 should be at least 28 bytes (header plus at least one fragment chunk) IPv4 with MF = 0 must be at least 20 bytes (just the header) IPv6 without frag header must be at least 40 bytes (just the header) IPv6 with frag header and M = 1 should be at least 56 bytes That's all I can see as *required*. Joe --------------DAA1DB8F6F9FE7BFA00846D7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi, Hemant,


On 1/16/2017 5:11 PM, Hemant Singh wrote:
Hi Joe,

Sorry for the delayed reply - I was out sick.  Please see in line below.

On Thu, Jan 12, 2017 at 1:48 PM, Joe Touch <touch@isi.edu> wrote:


 IMO, the only "attack" that exists for a firewall that can't handle 20 byte IPv4 packets at advertised line rate is on its consumers, i.e., they're lying about supporting IPv4 at the advertised line rate.

<hs> As I said in the past one attack on firrwalls or router ACLs is to craft an IPv4 header which is 60 bytes.  Then add 8 bytes at a portion of the TCP header. 
If you are talking about a single IP packet, that should not be considered an attack.

If you're talking about fragments, then  you need to describe the case more clearly. IMO, a firewall always needs to reassemble fragments.

Thus receivers receiving such a packet  cannot get to the SYNC TCP message type of the TCP header.  The hacker is also setting the MF bit in the Flags of the IP header when such a 68 byte packet has business to be fragmented on a 1500 Ethernet MTU link.

Remember that an IPv4 packet with DF=0 can be fragmented anywhere in the network and both IPv4 and IPv6 can be fragmented at the source.

IPv4 requires that a 68 byte packet can traverse the net without fragmentation but there are no rules that prohibit smaller packets or fragments. E.g., if you are sending a 100-byte packet and it needs to be fragmented down to 68 bytes, it's entirely valid to make the first fragment as 32 bytes. Anything longer than the IP header ought is defined as valid.

 
IMO, any ACL system or firewall that claims to check for information that might not be in the initial fragment MUST perform reassembly. Although routers aren't supposed to do reassembly, a device that needs to inspect upper layer protocols is no longer just a router, and is acting on behalf of an endpoint and doing part of the endpoint's job. It thus is justified in reassembling before acting.

<hs> Agree.  Some routers which a access concentrators such as a CMTS (Cable Modem Termination System) or a DSL BNG terminate fragmented traffic between the router and the broadband modem.  Thus, these routers can certainly be made robust to fragmented packet attacks.  
Wonder what the minimum size of an IPv6 packet is specified in any IPv6 RFC?  I checked the IPv6 Node requirements RFC and don't find any minimum.

 The minimum packet size would be 40 bytes, i.e., just the IPv6 header with no data. That could be used to trigger a device or set off an alarm; there need not be any data for a packet to be useful.

<hs> Sorry, I wasn't clear.  I meant the minimum sized IPv6 packet that won't be dropped by the network.   I would think 40 bytes plus at least 8 bytes of a TCP header would be valid?

The *minimum* for traffic is 40 bytes, the size of the smallest IPv6 header. As to fragments, the same rule applies as for IPv6.

Note - if a fragment - initial or otherwise - contains 0 bytes of payload, that might be considered invalid because it prevents reassembly from "making forward progress"; strictly, it's allowed, but it doesn't make sense to send such a message. However, both protocols allow it AFAICT.

 
The minimum IPv6 packet that an IPv6 network MUST be able to transit without fragmentation is 1280, as specified in RFC2460.

<hs> Yes, I am aware of the 1280 number.   Since IPv4 nodes are dropping an IPv4 packet which is smaller than 68 bytes.
That is broken behavior. The smallest valid IPv4 packet is 20 bytes, and the smallest that would still make progress in reassembly is 28; for IPv6 it would be 56 (40 for the IP header, 8 for the fragmentation extension, and 8 for the smallest fragment. There's absolutely no rule that all IPv6 fragments must be larger than 68 except for the last fragment.

Remember as well that the fragments don't always "break" in even pieces because a packet might traverse links with different MTUs.

E.g., consider traversing links with MTUs of 95 then 90:

200 (i.e., 180d + 20h) -> 92 (72d+20h), 92 (72d+20h), 36 (16d+20h) -> 84 (64d+20h), 28 (8d+20h), 84, 28, 36

I.e., small fragments can be generated by a succession of hops that have decreasing MTUs.

I was wondering, does IPv6 have some smallest size below which packets are dropped?

An IPv6 link can't drop anything that has at least an IPv6 header. If you want to say "it's safe to drop fragments that don't make sense", then anything with a fragment offset extension should be at least 56 bytes (48 would be just IP + FH, and that's not enough to make progress). But you have to look at the header to figure that out - otherwise, 40 bytes without a fragment header is still valid.

Is the IPv6 size in 48 bytes good or should we be smart to include the complete size of the TCP header and add 40 bytes of the IPv6 header?  This is the smallest packet an IPv6 network will accept.  Below this size the network drops packets.

IPv4 with MF = 1 should be at least 28 bytes (header plus at least one fragment chunk)
IPv4 with MF = 0 must be at least 20 bytes (just the header)

IPv6 without frag header must be at least 40 bytes (just the header)
IPv6 with frag header and M = 1 should be at least 56 bytes

That's all I can see as *required*.

Joe
--------------DAA1DB8F6F9FE7BFA00846D7-- From nobody Tue Jan 17 09:33:43 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81A951294FF for ; Tue, 17 Jan 2017 09:33:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 CHgjYAM7Ds8A for ; Tue, 17 Jan 2017 09:33:39 -0800 (PST) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D2DD129488 for ; Tue, 17 Jan 2017 09:33:38 -0800 (PST) Received: by mail-ua0-x231.google.com with SMTP id 96so107772777uaq.3 for ; Tue, 17 Jan 2017 09:33:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=msJ+xrKY+DDxzz2bWlWdJAZHNEEN5E95kOpoqrgRto8=; b=LVQu+fBv9phYWLoEeEbB9ydUPHvbfiT2UJX+mXVDvaaIXn8Yq/B/w6mNyb9sSTgt4v nZPAAtv3/PmpO0ez8MyW35AUAKgGuFVkhInUyFTbCfO+3P80JSmpqLFk+7c4DkRhFJwb Uf4zUh5NuDCK4E/U6SEDPDxhJTW9o7gs3o7okxQE8Fwzgtck2awPDXx/YnR1tlyqQQew LvoqORRYEw5tKidNhPfNzKWR9TDNx6V/Oi9F6orqD/aLBehcwCwk1s2ekx+Lp1Q3KC5m Yn0CNcvsdUqCiYHYs034DCf+/z86Me5CJZOomFPzgT5sHXr54h22iGZDoOhLtrNTKTbY coSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=msJ+xrKY+DDxzz2bWlWdJAZHNEEN5E95kOpoqrgRto8=; b=ocqhnWVgd2L7pJHH+3TH1lb6KiVWHWSZUmNcTtRGGFbWTkhha5ztiGhDgV5OlmyiAJ FZaQHeZUsZGCpc/3LBwForXUtoL/TlVopuLr9pSG5v1HqgBP6qgjFCxv6vB8SIY6EcjV e5xaPbcFUAgpdIKKcXVYHt+kzFP6foUXsa5VASEaQ+BmDIEI28eVBAR/8TsrnuXtuBtw UxEvo8XO3bc5dI2zDWISzK9MkkQgz2YkYsda3sPB5SWySZExRUqcXthG50DW0MCKUShQ XsYNPDsGwVKiRwobNbL2XwQrwFEgeLdfFCsWh0SDXtI113wN6D6AGEC6VofCtDqzqE6z IhZQ== X-Gm-Message-State: AIkVDXJE+AacgeSMDr4fhCMVd9XOEWKcR4qpsqGRbCNYpo7OC0Pzrj+G8uBP3TzovId3+TFwBNBm9d+Z90O+jw== X-Received: by 10.159.37.193 with SMTP id 59mr20909154uaf.9.1484674417650; Tue, 17 Jan 2017 09:33:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.2.235 with HTTP; Tue, 17 Jan 2017 09:33:07 -0800 (PST) In-Reply-To: <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> From: Mark Smith Date: Wed, 18 Jan 2017 04:33:07 +1100 Message-ID: To: Fernando Gont Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 17:33:40 -0000 On 18 January 2017 at 01:58, Fernando Gont wrote: > Hi, Ted, > > On 01/17/2017 11:04 AM, Ted Lemon wrote: > > That said, I have also heard complaints from quite a few ISPs deploying > IPv6 regarding why they can't just do dhcp, and have to do something > else to essentially get the same thing as in IPv4 (they only wanted > longer addresses, not learn new fancy stuff). And in that sense, their > concerns seem understandable, too. I think it is a generational thing. There is a generation of network engineers who've only known and been taught IPv4(+NAT). They would like IPv6 to be as close as possible to IPv4 because that is what they're familiar with. They won't have seen other layer 3 protocols, and how some of them were easier to operate and configure because they were developed after IPv4. (If I think about the operational and usability goals IPv6 should have, they're mainly set by my IPX and Appletalk experience, not my IPv4 experience.) The generation after will learn both IPv4(+NAT) and IPv6. They'll just accept more than one layer 3 protocol is necessary and that they work differently, as my generation did when we ran IPv4 as well as IPX, Appletalk etc. They'll do IPv6 the IPv6 way. This "IPv4+NAT only" generation will only last for a short period in the life of IPv6. We should be careful not to hobble IPv6 to suit their relatively limited world view. > So in that respect, at this point, > rather than fighting over a specific way to configure hosts (with the > current outcome of "you have to do both!"), I'd probably try to make > things easier/simpler for folks deploying v6, give them the two > protocols as fully-working *options*, and let them decide by themselves > whatever works better for them. > Choice isn't always a good thing, in particular when the choices are very similar or appear to be very similar. That can result in choice paralysis, were it is safer not to make a choice than deal with the consequences of making a bad or incorrect choice. Regards, Mark. > Cheers, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Jan 17 13:16:43 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E1B11294D3 for ; Tue, 17 Jan 2017 13:16:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.309 X-Spam-Level: X-Spam-Status: No, score=-0.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, SPF_PASS=-0.001] autolearn=no autolearn_force=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 vycXKFYUcQ_9 for ; Tue, 17 Jan 2017 13:16:40 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84C2F129495 for ; Tue, 17 Jan 2017 13:16:40 -0800 (PST) Received: from [192.168.3.101] (142-135-17-190.fibertel.com.ar [190.17.135.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 9B01282B19; Tue, 17 Jan 2017 22:16:36 +0100 (CET) To: Ted Lemon References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <6f3241eb-9d47-0a6e-7c0d-e9b5a69b86d0@si6networks.com> Date: Tue, 17 Jan 2017 13:05:07 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 21:16:42 -0000 On 01/17/2017 12:38 PM, Ted Lemon wrote: > On Jan 17, 2017, at 9:58 AM, Fernando Gont > wrote: >> 1) RDNSS was standardized not such a long time ago (should >> double-check, but..) after pro-dhcpv6 vendors had already >> implemented DHCPv6. > > It's been a little over six years, and there have been quite a few > Windows releases since then, so we can I think safely conclude that > if a vendor has not implemented it, it's not because they didn't have > an opportunity to do so. Agreed. [....] >> I don't. I don't care about what specific protocol I can use, as >> long as I can use one to support all my hosts (e.g., having Windows >> and others support RDNSS off-the-shelf works for me.. and if >> there's a way to help things in that direction (make such support a >> MUST), I'm game). > > Well, right now it's RECOMMENDED in RFC 6434. I suppose we could > update the RFC to say REQUIRED, but it's hard to understand why an > implementation would choose to ignore this recommendation if there > weren't some specific reason for doing so, so it might be worth > asking the vendors that don't implement RDNSS why they have chosen > not to. "Well, I like dhcpv6 and you like slaac. You don't implement my dhcv6 thing, I will not implement your slaac thing" or some version of it. >> That said, I have also heard complaints from quite a few ISPs >> deploying IPv6 regarding why they can't just do dhcp, and have to >> do something else to essentially get the same thing as in IPv4 >> (they only wanted longer addresses, not learn new fancy stuff). And >> in that sense, their concerns seem understandable, too. So in that >> respect, at this point, rather than fighting over a specific way to >> configure hosts (with the current outcome of "you have to do >> both!"), I'd probably try to make things easier/simpler for folks >> deploying v6, give them the two protocols as fully-working >> *options*, and let them decide by themselves whatever works better >> for them. > > Here I do not believe you are talking about RDNSS. It sounds like > you are saying "why can't some nodes simply _not_ implement SLAAC." Actually, they were complaining "why we can't just do dhcp(v6) as we do in IPv4?" > This is very far afield for a discussion of this particular document. > If you want to propose such a thing, you might want to start a > separate discussion. I wouldn't. I'm more in the camp of doing something to push RDNSS and/or get fully-working DHCPv6. I guess that for the same religious war we still don't have a default-route option in dhcpv6, so I guess the easier option would be to push rdnss (if doable). Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Jan 17 13:17:02 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFD85129594 for ; Tue, 17 Jan 2017 13:17:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.309 X-Spam-Level: X-Spam-Status: No, score=-0.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=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 ugfXet0Httpy for ; Tue, 17 Jan 2017 13:17:00 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BEA612951B for ; Tue, 17 Jan 2017 13:16:59 -0800 (PST) Received: from [192.168.3.101] (142-135-17-190.fibertel.com.ar [190.17.135.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 5B21482B22; Tue, 17 Jan 2017 22:16:55 +0100 (CET) To: Mark Smith References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: Date: Tue, 17 Jan 2017 14:43:50 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 21:17:01 -0000 On 01/17/2017 02:33 PM, Mark Smith wrote: > On 18 January 2017 at 01:58, Fernando Gont wrote: > >> That said, I have also heard complaints from quite a few ISPs deploying >> IPv6 regarding why they can't just do dhcp, and have to do something >> else to essentially get the same thing as in IPv4 (they only wanted >> longer addresses, not learn new fancy stuff). And in that sense, their >> concerns seem understandable, too. > > I think it is a generational thing. I think it's a *human* thing. Humans like familiar things, particularly when they want to do exactly the same thing they do with what they are familiar with. >> So in that respect, at this point, >> rather than fighting over a specific way to configure hosts (with the >> current outcome of "you have to do both!"), I'd probably try to make >> things easier/simpler for folks deploying v6, give them the two >> protocols as fully-working *options*, and let them decide by themselves >> whatever works better for them. > > Choice isn't always a good thing, in particular when the choices are > very similar or appear to be very similar. That can result in choice > paralysis, were it is safer not to make a choice than deal with the > consequences of making a bad or incorrect choice. What we currently have is essentially the worst possible outcome: have to provide duplicate information in two different protocols if you want to support, say, Android & Windows. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Jan 17 14:07:56 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 054141295AC for ; Tue, 17 Jan 2017 14:07:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 bZCg-7Oyu7ce for ; Tue, 17 Jan 2017 14:07:54 -0800 (PST) Received: from mail-qt0-x242.google.com (mail-qt0-x242.google.com [IPv6:2607:f8b0:400d:c0d::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 865E21295CB for ; Tue, 17 Jan 2017 14:07:54 -0800 (PST) Received: by mail-qt0-x242.google.com with SMTP id l7so24814466qtd.3 for ; Tue, 17 Jan 2017 14:07:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=jzhbL8NV2MO9SWF7L68Wmfe/MfKC0PPDo/w3XbapBc0=; b=rHylBv7phHSWvsJN74KJaAW58gaiTvd9hdAk8QiemlUwkESfltRY/5snYRqLOCISuQ Kjb5ca1lUnIkBtIBL6MWR9ks7FI74Jww9JJPQNw3lvepxaEls9CEdwjd1cJKujufPBQG 3/t1vWENjx10GLhuXW+RTEHvv5Mk/6sV6HJQsgCiiJpjoqQ9iRS0kYSgeajHbtJojC3M WwZmsAf2JpxtDFtKmolS6VYU9+QY+TfT2qIoDeD/sNULcLse7ihzts9iAg+CpOYeszDQ DiW5s9ZWhki9WneJJ1ShkyzwSIX7COOcX932UvgrWjTALoGb3oqyMUyp2nYkxXgRUACk jkjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=jzhbL8NV2MO9SWF7L68Wmfe/MfKC0PPDo/w3XbapBc0=; b=nm5CCHm2P1cka+kX/qhPDpYMxpxBNF02cp2Q651UcfvAkzG0SPXhUsppdUcRzzyQ0s Pvir5MnLTqgY1sRQXUxepFTM2/Xt1i2aHf6FSbpAFlcnRcIH0ig9Vk+4gJpwytjRtxOf rJ1+xtBsDvocR5etIgBbzY9nWRdABaiwL9miPOG/Ge/4uZuSfQn1KUVWMi0xzMzTGDWl KUurfDaEXi/rcKP31RCGk1GQkxrVToDa0Cuud4i+QRK+Wj42Q8ta6d38Z77se4BlebP4 QBjUWWRF/A3ShkzpUGduDNhn3AfkbWY4l0HeHq5r/bct/hbqi10xAShZNMtsArlrzDhP oCMA== X-Gm-Message-State: AIkVDXLPjBJthXSlWFJQJKbtVF/64mff0X3qfoJ5WbSkL3KZ8o0+acktAFpahi/yHEQXHCazj32yI0x75OqCrQ== X-Received: by 10.55.161.11 with SMTP id k11mr37464475qke.149.1484690873578; Tue, 17 Jan 2017 14:07:53 -0800 (PST) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.29 with HTTP; Tue, 17 Jan 2017 14:07:53 -0800 (PST) In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F45C2E981DF@nkgeml514-mbx.china.huawei.com> References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2E981DF@nkgeml514-mbx.china.huawei.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Tue, 17 Jan 2017 14:07:53 -0800 X-Google-Sender-Auth: cH41uJ9ChiHG0Ph6uXR1FDI-uUc Message-ID: To: "Liubing (Leo)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IPv6 Ops WG , "v6ops-chairs@tools.ietf.org" Subject: Re: [v6ops] Possible consensus of dhcpv6-slaac-problem draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 22:07:56 -0000 At Tue, 17 Jan 2017 03:13:31 +0000, "Liubing (Leo)" wrote: > 1) Re-phrase the document to make it more like a report and caution of current divergent behaviors, rather than stating "problems". > I think most of the texts could be kept, but with a different tone. The divergence analysis and the OSes behaviors are objective; whether it is a "problem" is subjective. In this document, we just keep a neutral position. > In this sense, I would request to change the draft name as e.g. "draft-ietf-v6ops-dhcpv6-slaac-implementation-divergence" > If in the future we all agree it is "Problem", then we can make a new draft discussing the fixes. [...] > I will do step 1) first within this week, and ask the WG for review. If we can get consensus, then we'll do step 2). > Does it sound ok? Personally, one of the main issues of dhcpv6-slaac-problem is not about behavior-only vs problem description, but that it talks about (seemingly) random topics most of which don't seem (to me) to have practical importance. Of course, what is important and what is not is quite subjective, so it's not surprising if some other people consider most/all of the topics are important. But my impression from the past and current discussion of the draft is that it's at least not only me. In this sense, just focusing on describing the random behaviors does not sound okay to me. What I want to see is to have some level of consensus on what is important and practical and focus on them. -- JINMEI, Tatuya From nobody Tue Jan 17 14:30:36 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 471681295A5 for ; Tue, 17 Jan 2017 14:30:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 rFAbgj17nOzh for ; Tue, 17 Jan 2017 14:30:34 -0800 (PST) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30B1B1294A1 for ; Tue, 17 Jan 2017 14:30:34 -0800 (PST) Received: by mail-ua0-x229.google.com with SMTP id 35so113959961uak.1 for ; Tue, 17 Jan 2017 14:30:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BIH+Oba8xYjjIAzEFSNdgX9YjEWU7r6lGP4o23rYtg0=; b=R80PoJJCV5cfNYG7DyZbQch6u5TJX7BUTThFL8mAjmCAQX2f/Zcaj4iVWhlicVZ4NZ 4zcbn7CBUBH/8fmDXVYC4zqNY73kTgE9FZtGtL9NZ7A9njP5DE0jepZa+VthkEOWS1ID bxSsRYpYVyf8AdhEuRKidgkHmuIYKl8lGk6MDrd0tuHwuBqUsuvu5mTTibJskZcTLfIX 6PItiYjoC7Amk5NtiVt0FPJnrOOq5F7pCKyYtVQwuZirJCXg5c/VYhUzyjVi7S75fZaw c5gY/XvQnmku2ocpfboaaGlGEiEM1EmgDbnbs2CYNI56mhSKD5xK3usOMBpKWGJXqabn OnuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BIH+Oba8xYjjIAzEFSNdgX9YjEWU7r6lGP4o23rYtg0=; b=pOUaBRcyinh3+w4nCPX1/BuTXBOmSJxyVuX/R3tYHWec5oDyx9FWs2NkKEQN8NRu4q K1sY6pBPxwdzWbbm5jU/4smsYKOFIbgKEkPn9+vLqUoqqsrR17oVBrPa3p6bNcJLv6ae XteMc+su6sdtohfGnAxkxeKX+28GQpZKgxyE2hoNWP//f5WeWzRpNXE8jtKEsYYmomAL rQxxt8oeyau06h8OQmhEMb9hA4E9uHc17wngzBFUjBnpYms5454Yr5Vo0wCKUQQSrPYa zCcxOvds2wnFMpSzbx8x/gp8mHqDRwc14RHhFeSMu4o+qFdaFqGBiYIAmXRIYtcVq8fg 6DxA== X-Gm-Message-State: AIkVDXKo4Zr961lr0zRSzOCBZXbK36AxIR9hW6EcdpMGfFs3cMyzsMZFc6rdRTZdRIrN8D9baEWAjl01d1ZiSg== X-Received: by 10.159.35.175 with SMTP id 44mr16257uao.28.1484692233208; Tue, 17 Jan 2017 14:30:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.2.235 with HTTP; Tue, 17 Jan 2017 14:30:02 -0800 (PST) In-Reply-To: <6f3241eb-9d47-0a6e-7c0d-e9b5a69b86d0@si6networks.com> References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <6f3241eb-9d47-0a6e-7c0d-e9b5a69b86d0@si6networks.com> From: Mark Smith Date: Wed, 18 Jan 2017 09:30:02 +1100 Message-ID: To: Fernando Gont Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 22:30:35 -0000 On 18 January 2017 at 03:05, Fernando Gont wrote: > On 01/17/2017 12:38 PM, Ted Lemon wrote: >> On Jan 17, 2017, at 9:58 AM, Fernando Gont >> wrote: >>> 1) RDNSS was standardized not such a long time ago (should >>> double-check, but..) after pro-dhcpv6 vendors had already >>> implemented DHCPv6. >> >> It's been a little over six years, and there have been quite a few >> Windows releases since then, so we can I think safely conclude that >> if a vendor has not implemented it, it's not because they didn't have >> an opportunity to do so. > > Agreed. > So the problem used to justify RDNSS was that a stateless DHCPv6 client was too heavy weight for low powered / embedded devices. That sounded reasonable at the time, however the more I've since thought about it, the more I think that justification is false. If a device doesn't have the resources to implement a stateless DHCPv6 client (i.e., implement just the parts of the DHCPv6 protocol required to handle parameters, but not address assignment/IA_* options), then it probably is too low end to be implementing IPv6. CPU and memory is always getting increasingly cheaper. RDNSS was never intended to be an alternative to stateless DHCPv6 for devices that aren't resource constrained. I'm now have the opinion that RDNSS really shouldn't exist, and the resulting confusion between using DHCPv6 or RAs for DNS information was also predictable and predicted. More broadly, why do people think DNS settings are the only ones a host needs? I don't understand that, and, for example, don't enjoy manually setting clocks on devices, so don't see why devices shouldn't also be provided with NTP server addresses, timezone addresses, and possibly many of the other options that DHCPv6 supports. Android is an interesting case. I'm happy with it using SLAAC for addresses, however I'd like it to support stateless dhcpv6 so that I can e.g., supply it with NTP server addresses, timezone information etc. I think that sort information is being "acquired" from other sources, such as the mobile network for time/timezone and embedding in firmware well known services that Google themselves provide e.g., DNS. A reasonable motivation is that if these services are provided locally and are performing badly, the end-user would assign blame to Google/Android rather than the provider of the badly performing underlying service. Regards, Mark. From nobody Tue Jan 17 14:54:34 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 348361293FC for ; Tue, 17 Jan 2017 14:54:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=steffann.nl 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 5M0RJg2eeq9d for ; Tue, 17 Jan 2017 14:54:31 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCF271294F5 for ; Tue, 17 Jan 2017 14:54:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id A550C5A; Tue, 17 Jan 2017 23:54:29 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:message-id:date:date:in-reply-to:from:from :subject:subject:mime-version:content-type:content-type:received :received; s=mail; t=1484693667; bh=I1U+gO4YKXkIMRY79X67K0ZgmwVM Z+Xaio5pVBoqbF0=; b=IBRlhoR0A2gF7ZaRj/b463GbKQM69QKRZAR6fFvsJzkb 0X488AvYEqodY9MIkVlC6VrTZ+x58vS56uI8j3sdlp6wD4xAWT5Qj8tKMMYpJBeq FdzXCvZ+5TWl/khL2jiU7i9djVruSIfWqoSHNKZK+ipMoWXWWN8pc0om9XP/CtM= X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id g4VJUSKErxGQ; Tue, 17 Jan 2017 23:54:27 +0100 (CET) Received: from [IPv6:2a02:a213:a300:9300:d9b7:bcd2:8366:18c] (unknown [IPv6:2a02:a213:a300:9300:d9b7:bcd2:8366:18c]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.sintact.nl (Postfix) with ESMTPSA id 547D858; Tue, 17 Jan 2017 23:54:27 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_15F99A5B-2EC9-4A44-9195-9A18E61550D7"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Clacks-Overhead: GNU Terry Pratchett From: Sander Steffann In-Reply-To: Date: Tue, 17 Jan 2017 23:54:28 +0100 Message-Id: <99204933-5CB6-4E89-BD6A-FD40136DF6F5@steffann.nl> References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.3124) Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 22:54:32 -0000 --Apple-Mail=_15F99A5B-2EC9-4A44-9195-9A18E61550D7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, > Op 17 jan. 2017, om 18:43 heeft Fernando Gont = het volgende geschreven: >=20 > What we currently have is essentially the worst possible outcome: have > to provide duplicate information in two different protocols if you = want > to support, say, Android & Windows. When giving IPv6 training this is always the point where I get strange = looks from my students. If there is one thing that gives my enterprise = customers the feeling that IPv6 is not ready for production then this is = it. I can explain to them that all the protocols that they need for = their deployment are available, but the fact that there are multiple = ways for "the network" to tell the device which settings to use and = different behaviour of devices in response to that (thanks for that = research Enno!) astonishes them. This is the reasons I fear the addition = of provisioning a default gateway with DHCPv6: even more diverging = behaviour between different (versions of) implementations. I personally don't mind which protocol provides what. I can see = different ways to run a network that all make sense but require = different tools and protocols. I would actually like something like: - provide all options in both RA and DHCPv6 (embed non-IA DHCPv6 options = in RA?) - if you want to multicast settings to all devices, use RA - if you want per-device settings, use DHCPv6 - if an option is provided by both RA and DHCPv6, prefer DHCPv6 (more = specific) This would allow a device to implement handling those options once = independent of which protocol provided them, and define behaviour when = the options contradict each other. And operating systems that don't = implement DHCPv6 can still receive the options in the RA. Want to = support exceptions to the settings from the RA: use DHCPv6. In such a = situation I wouldn't mind having a DHCPv6 option for the default = gateway, maybe some devices need a different gateway. At least it would = be clear how to implement it, and no "competing" ways of doing things = and religious battles that confuse people. One set of options with two = complementing ways to distribute them would be so much nicer. It's getting late. Maybe I should go to bed and dream about an IPv6 = internet without religious battles there ;-) Cheers! Sander --Apple-Mail=_15F99A5B-2EC9-4A44-9195-9A18E61550D7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJYfqCkAAoJEKAtA7D+JBO5OqMH/jEmXe3GvxlWdiQWkj2WXVV7 9LXqQiOKSWRS1aQ8XnPq6DJ3RdbzBye4ZySrHy7oKRxVCDi3JSK7KWObDYYWE08j C3Lhdl6Mjkt8JK/bh311+tUXCDBAOH6ZnofRtNPdmrG18yJuMQs2u7/PMnaWXTlZ 6+OtnE/M4A1F+CCUpOG31cZsiC90dB4su71J5tUqjIZstf9Q2xW3BPTLK6HIVnqO s43Rr86Xo193csWRFAo4JydVbsGT8GYX9z/SZtV3ynH3uCjW+2xwMs/PX2zgCrr1 Ri7BvR1uaxzZIUElN+wLP/BmVLcpkNYoewajTSXew65F3swhDImtt8Nr8w7OvD8= =Cv/W -----END PGP SIGNATURE----- --Apple-Mail=_15F99A5B-2EC9-4A44-9195-9A18E61550D7-- From nobody Tue Jan 17 14:57:11 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E6081293F3 for ; Tue, 17 Jan 2017 14:57:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 BcpNrsupr-NS for ; Tue, 17 Jan 2017 14:57:09 -0800 (PST) Received: from mail-pg0-x242.google.com (mail-pg0-x242.google.com [IPv6:2607:f8b0:400e:c05::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF2CC126D74 for ; Tue, 17 Jan 2017 14:57:08 -0800 (PST) Received: by mail-pg0-x242.google.com with SMTP id t6so4939862pgt.1 for ; Tue, 17 Jan 2017 14:57:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=wOFa1VNWBT/+jjil2N7dyHWl7/15WOh6M5/YmJi9ph4=; b=Kyvq+1+0F+F8SOczI7488TLDZIW9kqJnhLrswoOmNdAejD/ojcfNsGxaVx6HmubPrX d9J75awuQ6GwWChCtoyDwi4O5k3ZcYJxRFWtH48Cd6IpChsmLDOreikW8DJBNWQxkfe6 T5dvM7/S1PvEXNM2ka4NQt3S9nPJcRcpFiBQAHzIMxkYOW29qtg/A2uqsgAfoo21aAPs dig8xFHMGI4k2pkiepC4QwLu1sDLlV+ZRsjgUT/HnKfVpxmSDqYzhHIF0Qrm0Pc51iWI 1c/fpyKPZZC7EnwdRr+q/2opqeiGbeV2DeZDIW3DRo3DfT7mE7X0+NhhWMxWpgviKFWU OQeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=wOFa1VNWBT/+jjil2N7dyHWl7/15WOh6M5/YmJi9ph4=; b=b6uUGGx+kyiWAx/38NzCxhFP7Nge718rYJ6YCX32N8Mst7Gp3ygdAY3ihK+/pyrf53 XV3EFnzF8gAbkCKXeCyAqGT5B3RAXK/KzDlDZmyeYrRzQen1Qa1CFMHuFKySdgUciGZW 1zQrQPN1/bqVBpe8dvRrPoEF92kM29izOznFSDxbdK8gtUBEMk8+WTHkjt8R7N7NRb48 pYCw4bHyMCM8GjbXp0Scp2udDpNMz8olkASgwkoVlT2t5XokTZ5HvplqK1ZPSx9AWzLn xeg1pVgux7bsBJNALdfGe09hgaxRq/WZxAb30f5vNsbWIJj99f51pbHp5B+jjP0jzin9 /Q6A== X-Gm-Message-State: AIkVDXLu3iuGJtdQ+wsVcA5cljOQlHWQ8qpsQuPMFlAF7wOhkYcTAa9tn9kC7PEHBGX0kQ== X-Received: by 10.98.34.82 with SMTP id i79mr112058pfi.120.1484693828275; Tue, 17 Jan 2017 14:57:08 -0800 (PST) Received: from [192.168.178.21] ([118.148.125.53]) by smtp.gmail.com with ESMTPSA id q80sm58203725pfi.13.2017.01.17.14.57.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Jan 2017 14:57:07 -0800 (PST) To: Mark Smith , sthaug@nethelp.no References: <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <20170117.170305.74705723.sthaug@nethelp.no> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Wed, 18 Jan 2017 11:57:07 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Fernando Gont , v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 22:57:10 -0000 On 18/01/2017 05:52, Mark Smith wrote: ... > DHCPv6 is more capable, flexible and general purpose. Indeed. When campus network operators and ISPs tell us unambiguously, as they do, that they require feature equivalence between DHCP for IPv4 and DHCP for IPv6, we would be incredibly arrogant to ignore them. > (I'm not making the assertion that if you use DHCPv6 then you must use > it for addresses. That's a choice available, however I would use SLAAC > for addresses and stateless DHCPv6 for the other upper layer host > parameters.) Many campuses want to use DHCPv6 for address assignment, however. (That doesn't mean banning SLAAC, though apparently some do that too.) On 18/01/2017 06:33, Mark Smith wrote: ... > This "IPv4+NAT only" generation will only last for a short period in > the life of IPv6. We should be careful not to hobble IPv6 to suit > their relatively limited world view. Agreed, but feature-equivalence for DHCPv6 doesn't do that. The great thing about SLAAC is that it works very well *without* DHCPv6 in simple deployments. But unless we extend RAs to supply every parameter that DHCP can supply, DHCPv6 *will* be used in most large networks. Brian From nobody Tue Jan 17 15:29:51 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F9741295E7 for ; Tue, 17 Jan 2017 15:29:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 NOVMyfD4Irmr for ; Tue, 17 Jan 2017 15:29:48 -0800 (PST) Received: from mail-ua0-x241.google.com (mail-ua0-x241.google.com [IPv6:2607:f8b0:400c:c08::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 670B812711D for ; Tue, 17 Jan 2017 15:29:48 -0800 (PST) Received: by mail-ua0-x241.google.com with SMTP id 96so13738865uaq.2 for ; Tue, 17 Jan 2017 15:29:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=T+mnLNybKoVhy/9nUBCcyxht+fLh51A7TUOUZbLBeZQ=; b=KV+wYjyvjjbBXwgdN0jptIe1X7Cm00EreezM/T4b8jzkTR1k+kyUJaTELhJcy/lslg aWrAy1cZMlP5+3VHbtjnhMM1p9URFTnh9VoBmr2kGce8hgp25WMrOYZ7hP5J3CVUeQR5 kHc9BSl+woG+LfpipGZfrROo1jdWquIhMR8lNo/66myPIbnpkIo6ggYvs2ssUNIES6GY WilKTnZSKlw8gaBl3qdbxtLtmGrdlslfMk1SQZhdu/2OUvBlAvybA0wcZBeGmo10UkT3 OqFQYs7YhH8pFnps+mRm0+pVwg3jznMemOKDJU7TggdAtEm7L1PCM4K1FKW727SfZcKV Tqrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=T+mnLNybKoVhy/9nUBCcyxht+fLh51A7TUOUZbLBeZQ=; b=QPWwOTQPhe7YtjEt1nujDtIMVeFjD82DXCh4ebPMOc5Z0ivU8bYDIu7zwKDjyZ7T// mJs69jYIbtpPcepig0FAredanVOI9ReccaaQzq5IppMhYuxg4suv0iwWgpfiN3AJ9QrB EKejqm6STj68Q1ZrYqvdLpLWYE5CIedLdqZ1WPE+yTyFYkJMnT31DXNejzNss3KJEv53 LssNa4FFj0QDhORGGWSlWcwcxGtThPA1hwgTUJb2uYYP7CfR1JwXVdKGxGzyXGMvRd6o A1v/QkFQVTRcFijNb9z2GGuW8/qKh2l7C2pgT4OINI9ts45QoW4hGpIVNOupWA11Nznm Zn6g== X-Gm-Message-State: AIkVDXJG6Br1UkRQZOvIFahaSRvnbzCFKDYh1srCrXv4l0G3tVVs7C8F07ub75TlC1pNJIr+hqKY+d8Q/Wub2Q== X-Received: by 10.176.82.54 with SMTP id i51mr100007uaa.161.1484695787421; Tue, 17 Jan 2017 15:29:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.2.235 with HTTP; Tue, 17 Jan 2017 15:29:16 -0800 (PST) In-Reply-To: References: <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <20170117.170305.74705723.sthaug@nethelp.no> From: Mark Smith Date: Wed, 18 Jan 2017 10:29:16 +1100 Message-ID: To: Brian E Carpenter Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Fernando Gont , v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 23:29:49 -0000 On 18 January 2017 at 09:57, Brian E Carpenter wrote: > On 18/01/2017 05:52, Mark Smith wrote: > ... >> DHCPv6 is more capable, flexible and general purpose. > > Indeed. When campus network operators and ISPs tell us unambiguously, > as they do, that they require feature equivalence between DHCP for IPv4 > and DHCP for IPv6, we would be incredibly arrogant to ignore them. > >> (I'm not making the assertion that if you use DHCPv6 then you must use >> it for addresses. That's a choice available, however I would use SLAAC >> for addresses and stateless DHCPv6 for the other upper layer host >> parameters.) > > Many campuses want to use DHCPv6 for address assignment, however. So I am always interested to know what problem they're trying to solve then they say that. I expect it is address use/auditability for security purposes. I then wonder if they've put in place companion measures to prevent hosts from using addresses configured statically, or measures to prevent an entirely new prefix being brought up on the link by hosts via static configuration, that won't be recorded in the DHCPv6 address database. > (That doesn't mean banning SLAAC, though apparently some do that too.) > > On 18/01/2017 06:33, Mark Smith wrote: > ... >> This "IPv4+NAT only" generation will only last for a short period in >> the life of IPv6. We should be careful not to hobble IPv6 to suit >> their relatively limited world view. > > Agreed, but feature-equivalence for DHCPv6 doesn't do that. The great > thing about SLAAC is that it works very well *without* DHCPv6 in > simple deployments. But unless we extend RAs to supply every parameter > that DHCP can supply, Agree, that's what we want to avoid. > DHCPv6 *will* be used in most large networks. > What I'm not understanding is a seemingly common belief that DNS is the only parameter that needs to be configured on general purpose hosts, therefore only RDNSS is necessary, and therefore all hosts should support RDNSS. This is even though RDNSSs functionality is so limited compared to stateless DHCPv6, that the moment you need to deploy automated configuration of anything else, you're going to have to deploy (at least stateless) DHCPv6. If you deploy stateless DHCPv6 in the first place for DNS, you avoid issues and limitations that RDNSS has, and you can easily add providing other DHCPv6 supported parameters such as NTP at a later time. Regards, Mark. From nobody Tue Jan 17 15:41:48 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0432F129493 for ; Tue, 17 Jan 2017 15:41:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 UJ7Q_N1qo3S8 for ; Tue, 17 Jan 2017 15:41:45 -0800 (PST) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC89312711D for ; Tue, 17 Jan 2017 15:41:45 -0800 (PST) Received: by mail-pf0-x22a.google.com with SMTP id y143so65601220pfb.0 for ; Tue, 17 Jan 2017 15:41:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JNTRVNEctyQEieFWlMpTv8fw3tAtZ26f727IMzHgONc=; b=FjdxJKuZuu9LabHAbP/8ke83DDApEwv1vYoFgKR/VkxFLvu8K7XgmbO9Cc6fRfXjXn +0/V6KOeUqccGYkJ1O8GKq9ZKhCJlepqEQsEEPnTjtz5/6oWhB/CRdNvSFSRoCHv0Y87 C2t+l/1ZLilSlQP7pAVOBwBLONOkNJYy47Sl9GS3tI8MWelGEMfLTLtbmtLQ6iFB+Rg9 ryUWDkmPNxsTkgNTZGVnnUqLEXe+z/7HjExjM4KJ0YFkYbEilkev+LB1a1h+eZY9IVEX tGRvOVgC0aSy4x/W9VFCZVojP5mogXsXIvN3merQfFY9O0NkQlJToUBFNaygymlK9fRT ZxSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JNTRVNEctyQEieFWlMpTv8fw3tAtZ26f727IMzHgONc=; b=l3DO+awWVwlvii3ZaigPuyZgUMRjS8jZjyZHfrfocfjYteCx0bJ1iu0cXGq9U5Vy+L Li1mi2471M+j+hT6kAaq/IsaVq1lD4iyDX6jSIBtasRhH+5lxuqmJwZmCDnxHHp6YdK+ a0K/TXbnZaYIAaiUy2wIZYNqYa2IdRHCB/7S1YKgBzwT3SfffjM6jdu1newDqx9cw2c1 dXRDTCPCNVj/jG4Ka19JQecj/h7cBbZrVIUjqurATQihFrbIDNXN5wFOIYpcR4Xf7+vv I8AU8NLpPqzies8kE+K1/pWxOcEx5Nj5SmSjk2pQc33+vicMwcl7vfB2kFlbMoT6xTby 6v+w== X-Gm-Message-State: AIkVDXIrOmko03Y9M/GbiyrI74q70bhn/hqGxC2zPzVz/r2EhSSE5KxkGQjWjvEd+ET0YQ== X-Received: by 10.84.254.15 with SMTP id b15mr425015plm.114.1484696505296; Tue, 17 Jan 2017 15:41:45 -0800 (PST) Received: from [192.168.1.15] (wsip-184-191-158-59.sd.sd.cox.net. [184.191.158.59]) by smtp.gmail.com with ESMTPSA id u64sm58662651pgc.39.2017.01.17.15.41.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Jan 2017 15:41:44 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Fred Baker In-Reply-To: Date: Tue, 17 Jan 2017 15:41:43 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <20170117.170305.74705723.sthaug@nethelp.no> To: Mark Smith X-Mailer: Apple Mail (2.3259) Archived-At: Cc: Fernando Gont , v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 23:41:47 -0000 On Jan 17, 2017, at 3:29 PM, Mark Smith wrote: >=20 > So I am always interested to know what problem they're trying to solve > then they [want to use DHCPv6 for address assignment]. I expect it is = address use/auditability for > security purposes. I then wonder if they've put in place companion > measures to prevent hosts from using addresses configured statically, > or measures to prevent an entirely new prefix being brought up on the > link by hosts via static configuration, that won't be recorded in the > DHCPv6 address database. Something I have heard proposed, but I don't know the current details = of, is to freeze the neighbor cache in a router. Instead of asking the = router to send a neighbor solicit when it receives a message for an = unknown address, have it drop the message or forward it to a security = device. To that end, a host might use IEEE 802.1X to associate a MAC = address with an IP address (or two), and let something associated with = the 802.1X service configure the router with the neighbor entry, or = trigger it to do an NDP lookup. That has limits, of course; devices can communicate on-link without the = router. But the router can filter sessions in various ways.= From nobody Tue Jan 17 15:42:00 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C5331295EF for ; Tue, 17 Jan 2017 15:41:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 jX17YPM2r7qU for ; Tue, 17 Jan 2017 15:41:55 -0800 (PST) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 808481295EB for ; Tue, 17 Jan 2017 15:41:53 -0800 (PST) Received: by mail-pf0-x234.google.com with SMTP id f144so65514502pfa.2 for ; Tue, 17 Jan 2017 15:41:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JNTRVNEctyQEieFWlMpTv8fw3tAtZ26f727IMzHgONc=; b=tovL6tU94SQxUW0DMqLvSdYULsvz2CYoKlxhAqc1KG/9jrA1jKf6tjalYCskYbSyQ3 S249hzUffwoyr0cpDVBSyGpqvjVBYikHEs8YO4SOELzIxZm8DdLGiR/CUSTQ6Vkoq5i/ +qAo6wza5/vMsjEEXhRVIFka5FKGhTUigXVz1YUdZk73GgL+YmAmtCWcT2RcKNHA+R/K zuBuMqZsAKgkeURkE6AedUdupf5khKTchabJiOZ5VzKsJ+fFpf+IofphFHXtpX65dfGP fInRlLmY90c3vFt3I6/8BR5jsnmaURtFX7qq7INSGZcUk2T8mUDe9hKGkuriQm+prD/u ySQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JNTRVNEctyQEieFWlMpTv8fw3tAtZ26f727IMzHgONc=; b=YsnByf1iTdlCe0pK7eUo/R5Jw9qVD7m816f0rxTQQ92qjO4sWjZL96ldhSamLgrCM1 pI5hZP+XKQPKFoWbP1VYI99maRYRgGbdsXdbE0XLoAeoRRvwq9Mw9vZpmwFfhJ9Wq0Bt X0iavhU8cjhvYiXHo25BY+4Z3yz+TidGxbNmdP6g3v5aaTRInBoKDB3C3rqIsXvjK6FF WSc/8qx2gV2gQ0CwuLR4vBs73NqxL5BwTDguSrhQ68+57B60Erq+lfb+gSmJY120wGl+ 3PEiVR38RdXrhDSlg0SKjL7oMO4RoS1t/fhV5cDJcB+Kqk8gt50fviHNmwVjdwd1ABCy p5Aw== X-Gm-Message-State: AIkVDXL8CepQw3jpr7DhIntv1Ccm8kedS8P3kAzo3HCeJ0gCxfuNTWc97rgzpnXr2Eo9mQ== X-Received: by 10.84.224.133 with SMTP id s5mr418936plj.130.1484696513105; Tue, 17 Jan 2017 15:41:53 -0800 (PST) Received: from [192.168.1.15] (wsip-184-191-158-59.sd.sd.cox.net. [184.191.158.59]) by smtp.gmail.com with ESMTPSA id u64sm58662651pgc.39.2017.01.17.15.41.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Jan 2017 15:41:51 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Fred Baker In-Reply-To: Date: Tue, 17 Jan 2017 15:41:51 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <08ADFC55-117B-4085-A2DF-D003A682C065@gmail.com> References: <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <20170117.170305.74705723.sthaug@nethelp.no> To: Mark Smith X-Mailer: Apple Mail (2.3259) Archived-At: Cc: Fernando Gont , v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 23:41:58 -0000 On Jan 17, 2017, at 3:29 PM, Mark Smith wrote: >=20 > So I am always interested to know what problem they're trying to solve > then they [want to use DHCPv6 for address assignment]. I expect it is = address use/auditability for > security purposes. I then wonder if they've put in place companion > measures to prevent hosts from using addresses configured statically, > or measures to prevent an entirely new prefix being brought up on the > link by hosts via static configuration, that won't be recorded in the > DHCPv6 address database. Something I have heard proposed, but I don't know the current details = of, is to freeze the neighbor cache in a router. Instead of asking the = router to send a neighbor solicit when it receives a message for an = unknown address, have it drop the message or forward it to a security = device. To that end, a host might use IEEE 802.1X to associate a MAC = address with an IP address (or two), and let something associated with = the 802.1X service configure the router with the neighbor entry, or = trigger it to do an NDP lookup. That has limits, of course; devices can communicate on-link without the = router. But the router can filter sessions in various ways.= From nobody Tue Jan 17 15:52:26 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98BDB12940F for ; Tue, 17 Jan 2017 15:52:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 kqu9X3FF1kLA for ; Tue, 17 Jan 2017 15:52:24 -0800 (PST) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 334A2129408 for ; Tue, 17 Jan 2017 15:52:24 -0800 (PST) Received: by mail-ua0-x22c.google.com with SMTP id 35so115168846uak.1 for ; Tue, 17 Jan 2017 15:52:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=CaYnXeKSErJ3/6FgqZIiicEFQBLCzq2wvrvydNcPGg4=; b=UwxE3aLs6PXyxckRizVbxuyeFbDxNPNhzQ7DcLWWcgmZ79uoBguihYo7DFxhsY0bBi YWQi9Wtl76LQ8q0hUQYM0toeVqyKr4Im7fTWix88DgbUZu7nuH7t8dhNUqfQDDTgXCOU YdgB0/nof96ITZ4WZ2yV0ODg0RDvZTuOyos1hUTKomj2ODtZ9Bogypy0D11gt6y8pc/b yQ635/B2DfCtCcI3hG+cUAyHAzfprvM85dZPVApxywQnfVHKUY99142Dvh6jiFAT3Ong h2vRb+hu9ylK21Mlj9HxT6t+GCnZ9LCXOi75ZKjKRV8Fd5xlDTPfiQLLHRwoF0r39jjU J4gA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=CaYnXeKSErJ3/6FgqZIiicEFQBLCzq2wvrvydNcPGg4=; b=QguU3XuV63i2i/Wg0oYesy9d4xFz5oXKKdOLTa3OrP9aDXPYd/HEMn3PJMqbUSHaBG 2V9Q2onZ8DQ4zrebJbwMyxt3hjStAEQWaOLmt0QycLU9cYI1ikpEQAMc84Vtzp0Emh+i o9XJtxfGDH5PyieRqOBtf0Az3HsA6JkFknhAL3pPC2nKscXWR+nqNcd+yMUkKt8+qauP DGVJh2M/+yBleoVFUk0qN/ULKYFqWMpZiasDqbMYMg0iqh998PpbPzgrPv2PQJCepPtl sfeaRVfn40rgjr8CDCFd2vAu/TqE0QB2zwctXcoHVAohKoA9C7jxoFsrZieP/Gnegp+x rYhA== X-Gm-Message-State: AIkVDXIp5gkIOcY5363dsz1JGsXjus8jTCUB5xeMzBmPAjcbQ3DSGTQP+uQEQRzLUs9QG0JxWJaUOdpeKVs30g== X-Received: by 10.176.83.153 with SMTP id k25mr135057uaa.141.1484697143210; Tue, 17 Jan 2017 15:52:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.2.235 with HTTP; Tue, 17 Jan 2017 15:51:52 -0800 (PST) In-Reply-To: <99204933-5CB6-4E89-BD6A-FD40136DF6F5@steffann.nl> References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <99204933-5CB6-4E89-BD6A-FD40136DF6F5@steffann.nl> From: Mark Smith Date: Wed, 18 Jan 2017 10:51:52 +1100 Message-ID: To: Sander Steffann Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Fernando Gont , IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 23:52:25 -0000 On 18 January 2017 at 09:54, Sander Steffann wrote: > Hi, > >> Op 17 jan. 2017, om 18:43 heeft Fernando Gont he= t volgende geschreven: >> >> What we currently have is essentially the worst possible outcome: have >> to provide duplicate information in two different protocols if you want >> to support, say, Android & Windows. > > When giving IPv6 training this is always the point where I get strange lo= oks from my students. If there is one thing that gives my enterprise custom= ers the feeling that IPv6 is not ready for production then this is it. I ca= n explain to them that all the protocols that they need for their deploymen= t are available, but the fact that there are multiple ways for "the network= " to tell the device which settings to use and different behaviour of devic= es in response to that (thanks for that research Enno!) astonishes them. Th= is is the reasons I fear the addition of provisioning a default gateway wit= h DHCPv6: even more diverging behaviour between different (versions of) imp= lementations. > > I personally don't mind which protocol provides what. I can see different= ways to run a network that all make sense but require different tools and = protocols. I would actually like something like: > - provide all options in both RA and DHCPv6 (embed non-IA DHCPv6 options = in RA?) > - if you want to multicast settings to all devices, use RA > - if you want per-device settings, use DHCPv6 > - if an option is provided by both RA and DHCPv6, prefer DHCPv6 (more spe= cific) > > This would allow a device to implement handling those options once indepe= ndent of which protocol provided them, and define behaviour when the option= s contradict each other. And operating systems that don't implement DHCPv6 = can still receive the options in the RA. Want to support exceptions to the = settings from the RA: use DHCPv6. In such a situation I wouldn't mind havin= g a DHCPv6 option for the default gateway, maybe some devices need a differ= ent gateway. At least it would be clear how to implement it, and no "compet= ing" ways of doing things and religious battles that confuse people. One se= t of options with two complementing ways to distribute them would be so muc= h nicer. > > It's getting late. Maybe I should go to bed and dream about an IPv6 inter= net without religious battles there ;-) > So none this is religious, or if people participating are being religious, then they shouldn't be participating. Engineering is supposed to be about being objective, and debating and weighing up the pros and cons of various options. Implementing every option every where to try to provide everybody with their favourite method ("provide all options in both RA and DHCPv6") just creates complexity, confusion, more code to write and more things that can break. I think when a discussion like this gets to this point, it is worth revisiting the problem or problems being solved. I think there are two problems to be/being solved: - providing hosts with specific link layer 3 parameters, meaning parameters that may be incorrect, irrelevant and unrelated on a different link, and shouldn't be made available on a different link (if the values are the same across different links, they are different instances of the values that happen to be the same value) - providing hosts with upper layer parameters that are not specific to and independent of the link the host is currently attached to RA options, with exception to the RDNSS options, all solve the first problem, and it is right that a local device attached to the link provides the parameters for the link. Address assignment is a link specific subset problem, so providing link layer specific parameters to suit address generation/assignment on the link is also solving this problem. DHCPv6 options, with exception to the IA_NA/IA_TA options, all solve the second problem, and since they're not link specific, and can be host specific, it means that regardless of where the host attaches, it isn't a requirement that the device providing them resides on the same link as the host, as long as the configuration request messages from the host can reach the configuration server (which we solve with an on-link DHCPv6 relay). DHCPv4 conflated these separate problems, however I think that is a consequence of the evolution of address and host configuration for Internet hosts. This conflation is being carried across to IPv6 because of familiarity, even though IPv6 has mostly and in my opinion correctly treated the two problems as separate ones. Somewhat related, the SLAAC/IPX method/model using link-layer addresses as layer 3 host addresses looks to be the original IPv4 model - see RFC796 - "ADDRESS MAPPINGS", "Internet to Local Net Address Mappings". That fits with solving a link specific layer 3 addressing problem local to the link where the problem exists. We probably really only ended up with DHCPv4 for address assignment because IPv4 addresses weren't big enough to carry useful amounts or the whole of the Ethernet address, unlike the link-layer addresses described in RFC796. The ARP RFC seems to allude to this: "However, the 10Mbit Ethernet requires 48.bit addresses on the physical cable, yet most protocol addresses are not 48.bits long, nor do they necessarily have any relationship to the 48.bit Ethernet address of the hardware. For example, CHAOS addresses are 16.bits, DOD Internet addresses are 32.bits, and Xerox PUP addresses are 8.bits." Regards, Mark. From nobody Tue Jan 17 17:42:52 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF781294AE for ; Tue, 17 Jan 2017 17:42:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 c0tbfEWaN8T9 for ; Tue, 17 Jan 2017 17:42:49 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8560129481 for ; Tue, 17 Jan 2017 17:42:48 -0800 (PST) Received: from [192.168.3.101] (142-135-17-190.fibertel.com.ar [190.17.135.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 630DD800BC; Wed, 18 Jan 2017 02:42:44 +0100 (CET) To: Mark Smith References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <6f3241eb-9d47-0a6e-7c0d-e9b5a69b86d0@si6networks.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: Date: Tue, 17 Jan 2017 22:35:25 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 01:42:50 -0000 On 01/17/2017 07:30 PM, Mark Smith wrote: > On 18 January 2017 at 03:05, Fernando Gont wrote: >> On 01/17/2017 12:38 PM, Ted Lemon wrote: >>> On Jan 17, 2017, at 9:58 AM, Fernando Gont >>> wrote: >>>> 1) RDNSS was standardized not such a long time ago (should >>>> double-check, but..) after pro-dhcpv6 vendors had already >>>> implemented DHCPv6. >>> >>> It's been a little over six years, and there have been quite a few >>> Windows releases since then, so we can I think safely conclude that >>> if a vendor has not implemented it, it's not because they didn't have >>> an opportunity to do so. >> >> Agreed. >> > > So the problem used to justify RDNSS was that a stateless DHCPv6 > client was too heavy weight for low powered / embedded devices. Should could the lines of code, spec pages but... ND seems to be on the same order of complexity, at the very least. > That > sounded reasonable at the time, however the more I've since thought > about it, the more I think that justification is false. If a device > doesn't have the resources to implement a stateless DHCPv6 client > (i.e., implement just the parts of the DHCPv6 protocol required to > handle parameters, but not address assignment/IA_* options), then it > probably is too low end to be implementing IPv6. CPU and memory is > always getting increasingly cheaper. +1 > RDNSS was never intended to be an alternative to stateless DHCPv6 for > devices that aren't resource constrained. > > I'm now have the opinion that RDNSS really shouldn't exist, and the > resulting confusion between using DHCPv6 or RAs for DNS information > was also predictable and predicted. >From that pov, things are getting even worse: wasn't there a proposal do do kind of DHCPv6-PD with RAs? > More broadly, why do people think DNS settings are the only ones a > host needs? I guess the feeling is not that they are the only ones, but that to quite an extent, they are kind of as basic as having an IPv6 address. > Android is an interesting case. I'm happy with it using SLAAC for > addresses, however I'd like it to support stateless dhcpv6 so that I > can e.g., supply it with NTP server addresses, timezone information > etc. Yes, it fails to implement DHCPv6. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Jan 17 17:43:05 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55629129526 for ; Tue, 17 Jan 2017 17:43:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 dSrmLR6MEt_o for ; Tue, 17 Jan 2017 17:42:55 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50CE11294F7 for ; Tue, 17 Jan 2017 17:42:55 -0800 (PST) Received: from [192.168.3.101] (142-135-17-190.fibertel.com.ar [190.17.135.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id B38D98240E; Wed, 18 Jan 2017 02:42:51 +0100 (CET) To: Brian E Carpenter , Mark Smith , sthaug@nethelp.no References: <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <20170117.170305.74705723.sthaug@nethelp.no> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <13645a52-76f1-be8a-68e2-ad6d110a3315@si6networks.com> Date: Tue, 17 Jan 2017 22:42:11 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 01:43:00 -0000 Hi, Brian, On 01/17/2017 07:57 PM, Brian E Carpenter wrote: > On 18/01/2017 05:52, Mark Smith wrote: > ... >> DHCPv6 is more capable, flexible and general purpose. > > Indeed. When campus network operators and ISPs tell us unambiguously, > as they do, that they require feature equivalence between DHCP for IPv4 > and DHCP for IPv6, we would be incredibly arrogant to ignore them. +1 >> (I'm not making the assertion that if you use DHCPv6 then you must use >> it for addresses. That's a choice available, however I would use SLAAC >> for addresses and stateless DHCPv6 for the other upper layer host >> parameters.) > > Many campuses want to use DHCPv6 for address assignment, however. > (That doesn't mean banning SLAAC, though apparently some do that too.) Same thing for DHCPv6. And have a hard time at understanding the current mess. > On 18/01/2017 06:33, Mark Smith wrote: > ... >> This "IPv4+NAT only" generation will only last for a short period in >> the life of IPv6. We should be careful not to hobble IPv6 to suit >> their relatively limited world view. > > Agreed, but feature-equivalence for DHCPv6 doesn't do that. The great > thing about SLAAC is that it works very well *without* DHCPv6 in > simple deployments. But unless we extend RAs to supply every parameter > that DHCP can supply, DHCPv6 *will* be used in most large networks. Feature equivalence would probably be the best option. But at the very least, I wished we had a default route option for IPv6, and RDNSS in all ND implementations. Thus, a large network where DHCPv6 is employed to provide all sorts of information can get all devices to work. I find it hard to call "IPv6-enabled" a devices that connects to such network and cannot talk. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Jan 17 18:46:01 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B06EE12963C for ; Tue, 17 Jan 2017 18:45:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.42 X-Spam-Level: X-Spam-Status: No, score=-7.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 lu9FCI3QPtXF for ; Tue, 17 Jan 2017 18:45:57 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5635B12963A for ; Tue, 17 Jan 2017 18:45:56 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CZA67260; Wed, 18 Jan 2017 02:45:53 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 18 Jan 2017 02:45:52 +0000 Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Wed, 18 Jan 2017 10:45:38 +0800 From: "Liubing (Leo)" To: =?utf-8?B?56We5piO6YGU5ZOJ?= Thread-Topic: [v6ops] Possible consensus of dhcpv6-slaac-problem draft Thread-Index: AQHScG+u/Kql0lmeGEKlzbtVJBMOt6E8tVCAgADJwJA= Date: Wed, 18 Jan 2017 02:45:38 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45C2E986B1@nkgeml514-mbx.china.huawei.com> References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2E981DF@nkgeml514-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.191.175] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0208.587ED6E2.00AF, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 53f4ebddcc65588dc06dd05692f6e718 Archived-At: Cc: IPv6 Ops WG , "v6ops-chairs@tools.ietf.org" Subject: Re: [v6ops] Possible consensus of dhcpv6-slaac-problem draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 02:45:59 -0000 SGkgSmlubWVpLA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogamlubWVpLnRh dHV5YUBnbWFpbC5jb20gW21haWx0bzpqaW5tZWkudGF0dXlhQGdtYWlsLmNvbV0gT24gQmVoYWxm IE9mIOelnuaYjumBlOWTiQ0KU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDE4LCAyMDE3IDY6MDgg QU0NClRvOiBMaXViaW5nIChMZW8pDQpDYzogSVB2NiBPcHMgV0c7IHY2b3BzLWNoYWlyc0B0b29s cy5pZXRmLm9yZw0KU3ViamVjdDogUmU6IFt2Nm9wc10gUG9zc2libGUgY29uc2Vuc3VzIG9mIGRo Y3B2Ni1zbGFhYy1wcm9ibGVtIGRyYWZ0DQoNCkF0IFR1ZSwgMTcgSmFuIDIwMTcgMDM6MTM6MzEg KzAwMDAsDQoiTGl1YmluZyAoTGVvKSIgPGxlby5saXViaW5nQGh1YXdlaS5jb20+IHdyb3RlOg0K DQo+IDEpIFJlLXBocmFzZSB0aGUgZG9jdW1lbnQgdG8gbWFrZSBpdCBtb3JlIGxpa2UgYSByZXBv cnQgYW5kIGNhdXRpb24gb2YgY3VycmVudCBkaXZlcmdlbnQgYmVoYXZpb3JzLCByYXRoZXIgdGhh biBzdGF0aW5nICJwcm9ibGVtcyIuDQo+IEkgdGhpbmsgbW9zdCBvZiB0aGUgdGV4dHMgY291bGQg YmUga2VwdCwgYnV0IHdpdGggYSBkaWZmZXJlbnQgdG9uZS4gVGhlIGRpdmVyZ2VuY2UgYW5hbHlz aXMgYW5kIHRoZSBPU2VzIGJlaGF2aW9ycyBhcmUgb2JqZWN0aXZlOyB3aGV0aGVyIGl0IGlzIGEg InByb2JsZW0iIGlzIHN1YmplY3RpdmUuIEluIHRoaXMgZG9jdW1lbnQsIHdlIGp1c3Qga2VlcCBh IG5ldXRyYWwgcG9zaXRpb24uDQo+IEluIHRoaXMgc2Vuc2UsIEkgd291bGQgcmVxdWVzdCB0byBj aGFuZ2UgdGhlIGRyYWZ0IG5hbWUgYXMgZS5nLiAiZHJhZnQtaWV0Zi12Nm9wcy1kaGNwdjYtc2xh YWMtaW1wbGVtZW50YXRpb24tZGl2ZXJnZW5jZSINCj4gSWYgaW4gdGhlIGZ1dHVyZSB3ZSBhbGwg YWdyZWUgaXQgaXMgIlByb2JsZW0iLCB0aGVuIHdlIGNhbiBtYWtlIGEgbmV3IGRyYWZ0IGRpc2N1 c3NpbmcgdGhlIGZpeGVzLg0KWy4uLl0NCj4gSSB3aWxsIGRvIHN0ZXAgMSkgZmlyc3Qgd2l0aGlu IHRoaXMgd2VlaywgYW5kIGFzayB0aGUgV0cgZm9yIHJldmlldy4gSWYgd2UgY2FuIGdldCBjb25z ZW5zdXMsIHRoZW4gd2UnbGwgZG8gc3RlcCAyKS4NCj4gRG9lcyBpdCBzb3VuZCBvaz8NCg0KUGVy c29uYWxseSwgb25lIG9mIHRoZSBtYWluIGlzc3VlcyBvZiBkaGNwdjYtc2xhYWMtcHJvYmxlbSBp cyBub3QgYWJvdXQgYmVoYXZpb3Itb25seSB2cyBwcm9ibGVtIGRlc2NyaXB0aW9uLCBidXQgdGhh dCBpdCB0YWxrcyBhYm91dA0KKHNlZW1pbmdseSkgcmFuZG9tIHRvcGljcyBtb3N0IG9mIHdoaWNo IGRvbid0IHNlZW0gKHRvIG1lKSB0byBoYXZlIHByYWN0aWNhbCBpbXBvcnRhbmNlLiAgDQpbQmlu Z10gSSBkb24ndCBxdWl0ZSB1bmRlcnN0YW5kIHdoYXQgeW91IHNhaWQgInJhbmRvbSB0b3BpY3Mi IG1lYW4uIFRoaXMgZG9jdW1lbnQgaXMgYWN0dWFsbHkgZm9jdXNpbmcgb24gYSB2ZXJ5IHNwZWNp ZmljIHRvcGljIC0gdGhlIGFtYmlndWl0eSBvZiB0aGUgTS9PIGZsYWdzLCBhbmQgdGhlIGRpdmVy Z2VudCBiZWhhdmlvcnMgY2F1c2VkIGJ5IHRoZSBhbWJpZ3VpdHkuDQpXZSBoYWQgYSAoYXMgbXVj aCBhcyB3ZSBjb3VsZCBkaWQpIGNvbXByZWhlbnNpdmUgYW5hbHlzaXMgb2YgdGhlIGFtYmlndWl0 eSBwb3NzaWJpbGl0aWVzIGZyb20gdGhlIGVhcmx5IHZlcnNpb25zIGRyYWZ0cy4gQW5kIHdlIG9i c2VydmVkIGRpdmVyZ2VuY2Ugb24gZWFjaCBvZiB0aGUgcG9zc2liaWxpdGllcy4gU28sIHBlcnNv bmFsbHkgSSBkb24ndCB0aGluayB0aGUgZHJhZnQgaXMgZGlzY3Vzc2luZyBzb21ldGhpbmcgcmFu ZG9tbHkuDQoNCk9mIGNvdXJzZSwgd2hhdCBpcyBpbXBvcnRhbnQgYW5kIHdoYXQgaXMgbm90IGlz IHF1aXRlIHN1YmplY3RpdmUsIHNvIGl0J3Mgbm90IHN1cnByaXNpbmcgaWYgc29tZSBvdGhlciBw ZW9wbGUgY29uc2lkZXIgbW9zdC9hbGwgb2YgdGhlIHRvcGljcyBhcmUgaW1wb3J0YW50LiANCkJ1 dCBteSBpbXByZXNzaW9uIGZyb20gdGhlIHBhc3QgYW5kIGN1cnJlbnQgZGlzY3Vzc2lvbiBvZiB0 aGUgZHJhZnQgaXMgdGhhdCBpdCdzIGF0IGxlYXN0IG5vdCBvbmx5IG1lLg0KW0JpbmddIFRoZXJl IHdlcmUgc2V2ZXJhbCBwZW9wbGUgZG9uJ3QgYWdyZWUgdGhlICJwcm9ibGVtcyIgZGlzY3Vzc2Vk IGluIHRoaXMgZG9jdW1lbnQgd2VyZSAicmVhbGx5IHByb2JsZW1zIi4gSSB1bmRlcnN0YW5kIGl0 IGlzIG5vdCBlYXN5IHRvIGdldCBjb25zZW5zdXMuDQpCdXQgSSBhbHNvIGhhdmUgYW4gaW1wcmVz c2lvbiB0aGF0IHBlb3BsZSBpbiBnZW5lcmFsIHRoaW5rIGl0J3MgZ29vZCB0byByZWNvcmQgYW5k IHB1Ymxpc2ggdGhlIGFtYmlndWl0eSBhbmQgdGhlIGRpdmVyZ2VudCBiZWhhdmlvcnMuDQoNCklu IHRoaXMgc2Vuc2UsIGp1c3QgZm9jdXNpbmcgb24gZGVzY3JpYmluZyB0aGUgcmFuZG9tIGJlaGF2 aW9ycyBkb2VzIG5vdCBzb3VuZCBva2F5IHRvIG1lLiAgDQpXaGF0IEkgd2FudCB0byBzZWUgaXMg dG8gaGF2ZSBzb21lIGxldmVsIG9mIGNvbnNlbnN1cyBvbiB3aGF0IGlzIGltcG9ydGFudCBhbmQg cHJhY3RpY2FsIGFuZCBmb2N1cyBvbiB0aGVtLg0KW0JpbmddIEFzIHlvdSBzYWlkLCB3aGF0IGlz IGltcG9ydGFudCBhbmQgd2hhdCBpcyBub3QgaXMgcXVpdGUgc3ViamVjdGl2ZS4gU28gd2h5IG5v dCB3ZSBqdXN0IGtlZXAgdGhlIG9iamVjdGl2ZSBmYWN0IGFuZCBsZXQgdGhlIHJlYWRlcnMvYWRt aW5pc3RyYXRvcnMgZGVjaWRlIGFjY29yZGluZyB0byB0aGVpciBzcGVjaWZpYyBzaXR1YXRpb24u DQoNClJlZ2FyZHMsDQpCaW5nDQoNCi0tDQpKSU5NRUksIFRhdHV5YQ0K From nobody Tue Jan 17 18:48:39 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D543129639 for ; Tue, 17 Jan 2017 18:48:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 WSUyBMdDWueM for ; Tue, 17 Jan 2017 18:48:36 -0800 (PST) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B3A8129619 for ; Tue, 17 Jan 2017 18:48:36 -0800 (PST) Received: by mail-vk0-x229.google.com with SMTP id r136so161745vke.1 for ; Tue, 17 Jan 2017 18:48:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uZUHaQ16OajejojJWyyHgcWqd3KEnsLT/dUqUfiOIqk=; b=db244WVWHqovKW2I3FJPaj9qUpMnoSnIEKncguGVG5+9PNyosAkvSKWDoxeYuIODmk cOVgd7CT2pJMuqq/3ud3+A5tSjjimaHN1fHkW8GDIb1c/jb2JgWR6ZLQMcrz0pIlbjLT 249BuWFyabWoSoq9U6zpGQ6c8VhgnjBw63fEcez3M1K9lI7EWI2UDqO3nXC8nlcOquLK Dd1s7hu2Ga5E22jrKvUkPIOe93AfZ8amU4K8GBQaxpAMMBHsAqbAlTXv0NSAtwPlF0RM USG5b5s72L4wtmk8UAb9g170b0bUUMgHjVCluuAP+319GQNG4CC6chbqitsF1XkcBEoY nGJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uZUHaQ16OajejojJWyyHgcWqd3KEnsLT/dUqUfiOIqk=; b=A58EEeLBTaVMul4NIxcM6fdeZP5R1pMjhG6TmeDtXimOfhjqR6fBoebrCg5nBBRZix GpLRfs0iY+cTmFiSYXDID/og70NQ99yGt0B+bo8eUC7oXwCiaY8NEis31EefLpwEFygl ER34vxZ8Q/9vYuLc/GdkA6xPWusmLfPdM8UIw2gAZDjcsViwnQeOJkVtLDXZ/Hli/hj2 2Q4VCy6MSM0eFMYYbGZWoMXJnPofuqG9cKnU1+/+vyR2XpkcmWCAFtn/8EUFdVJTUoqT XXKARDFehN1j4GchqNn4Eh+6uvK13eOIM6xX+q1IM0NPlZY0CA646KYnJ1rY9znRzoN/ UrLw== X-Gm-Message-State: AIkVDXL4i4GGEqz8xjVEBQnaE2DSXVHdmG6BE1ilj/wK2VqtEJ5VvPCKuFGm9ce8Cp5lZ4EPGeLHQJi8XULl/A== X-Received: by 10.31.183.136 with SMTP id h130mr110483vkf.131.1484707715657; Tue, 17 Jan 2017 18:48:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.2.235 with HTTP; Tue, 17 Jan 2017 18:48:05 -0800 (PST) In-Reply-To: References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <6f3241eb-9d47-0a6e-7c0d-e9b5a69b86d0@si6networks.com> From: Mark Smith Date: Wed, 18 Jan 2017 13:48:05 +1100 Message-ID: To: Fernando Gont Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 02:48:38 -0000 On 18 January 2017 at 12:35, Fernando Gont wrote: > On 01/17/2017 07:30 PM, Mark Smith wrote: >> On 18 January 2017 at 03:05, Fernando Gont wrote: >>> On 01/17/2017 12:38 PM, Ted Lemon wrote: >>>> On Jan 17, 2017, at 9:58 AM, Fernando Gont >>>> wrote: >>>>> 1) RDNSS was standardized not such a long time ago (should >>>>> double-check, but..) after pro-dhcpv6 vendors had already >>>>> implemented DHCPv6. >>>> >>>> It's been a little over six years, and there have been quite a few >>>> Windows releases since then, so we can I think safely conclude that >>>> if a vendor has not implemented it, it's not because they didn't have >>>> an opportunity to do so. >>> >>> Agreed. >>> >> >> So the problem used to justify RDNSS was that a stateless DHCPv6 >> client was too heavy weight for low powered / embedded devices. > > Should could the lines of code, spec pages but... ND seems to be on the > same order of complexity, at the very least. > > >> That >> sounded reasonable at the time, however the more I've since thought >> about it, the more I think that justification is false. If a device >> doesn't have the resources to implement a stateless DHCPv6 client >> (i.e., implement just the parts of the DHCPv6 protocol required to >> handle parameters, but not address assignment/IA_* options), then it >> probably is too low end to be implementing IPv6. CPU and memory is >> always getting increasingly cheaper. > > +1 > > > >> RDNSS was never intended to be an alternative to stateless DHCPv6 for >> devices that aren't resource constrained. >> >> I'm now have the opinion that RDNSS really shouldn't exist, and the >> resulting confusion between using DHCPv6 or RAs for DNS information >> was also predictable and predicted. > > >From that pov, things are getting even worse: wasn't there a proposal do > do kind of DHCPv6-PD with RAs? > I think there was at one stage. The fundamental motivation to try to use RAs (or more generally, a single and deployed protocol) for everything is understandable. However at some point it is trying to use the protocol far beyond what it was designed for. It's less understandable when there is already a protocol that can do it and that just needs to be deployed if necessary. The effort to update and deploy the later version of the existing protocol is going to be similar if not more than deploying the existing and available protocol that solves the problem. > >> More broadly, why do people think DNS settings are the only ones a >> host needs? > > I guess the feeling is not that they are the only ones, but that to > quite an extent, they are kind of as basic as having an IPv6 address. > > The conversations I come across tend to seem to be saying RDNSS instead of saying RDNSS + stateless DHCPv6 if necessary to supply more parameters. In other words, the view point seems to be RDNSS only, which is why it seems people are implying that DNS is the only necessary configuration parameter. (I don't think RDNSS + stateful DHCPv6 is a good option either - just use stateful DHCPv6 in the first place and be done with, just that if people said that, then it makes it clear they understand that host automated configuration involves more than just DNS.) > >> Android is an interesting case. I'm happy with it using SLAAC for >> addresses, however I'd like it to support stateless dhcpv6 so that I >> can e.g., supply it with NTP server addresses, timezone information >> etc. > > Yes, it fails to implement DHCPv6. > One thing I'm careful to do is to qualify whether I'm talking about stateless or stateful DHCPv6, because one is a much simpler subset of the other. I would like Android to have a stateless DHCPv6 implementation, so parameters such as DNS, NTP, timezone etc. can be set on it. I don't really care if it has a stateful DHCPv6 implementation, because I don't think it is properly solving the tracking/auditing problem people think it is. If a stateful DHCPv6 implementation doesn't exist, then people will look for another solution to their tracking/auditing problem (such as scraping ND cache entries, or using 802.1X to record a better and more accurate end-user identity that can then be mapped to a set of arbitrary L2/L3 addresses that may change over time as Fred mentioned), and that solution will probably more effectively achieve their tracking/auditing goal. Regards, Mark. From nobody Tue Jan 17 19:07:39 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A54A71294A7 for ; Tue, 17 Jan 2017 19:07:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 HXfkevxD6riq for ; Tue, 17 Jan 2017 19:07:36 -0800 (PST) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D83B1293E8 for ; Tue, 17 Jan 2017 19:07:36 -0800 (PST) Received: by mail-qk0-x231.google.com with SMTP id s140so617352qke.0 for ; Tue, 17 Jan 2017 19:07:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=iZeFUXXEZNRCDqrxlS3KtZ5SM0q1iS+8zmSJcv12qIY=; b=l+f8jAO6HLBXhBI31I4u4wHerl97mANtX8/72DudRkJsIXjQZruOHL4fT1v9YCb5N1 Y/SsWd5SLzkBMTaVNR7ycZ5ftE0XtwMvD3sB9dh3LkF0LRCvPXm6KlWa0MoUN9RxzAMA fHCQpTTbFhpQcub9Q/ckldHYVGop11+yEda8UBHViuoiOr5CeP6Uaw2ZH0wyM2uVROkj dzXKQhjPRjC/poUtWv4qCyKjaaWDUlai/r+xG3ulTUXemrqPCBwSwME8gCVXYSmtz9F1 J33OmrlDWztugeWGrdQrh1K+f4Yakd9G49VLEpWe0Hvbw6xQEZkKlhdFcDhmyjJZ5+ko V5Vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=iZeFUXXEZNRCDqrxlS3KtZ5SM0q1iS+8zmSJcv12qIY=; b=DXChFTkrVBE4s0XLmSW2eYUSiGvPnxxKpdCpHKe1fKJV6wphKK5HWV30yHDILumZHE 726AR/sMLHeRWI0xm4HJBErosQ4Bgs+XKE/6cXQLAKnC4Ibi1Dli3waNQmJ/LZAJFBrq owfe3f1idhCtT4Gd3GNu2gXkuBP2ZEnsia1OLltjjYUmIKzXLT/lFjDbI4zCY5X9kjLp ZrfyjZBR0D5+iuwpR5mjwYlMwME7Fk+Lro49N5BVL0jf9BLO2LEXJs7DQmcZnZH97fGK m673HniiLCH8Iu46f5cbxIMUBEyzv/+r4qJnwuhpJEgdqXBz0dUrXN/O2LWvq9arte7h nJjw== X-Gm-Message-State: AIkVDXIMecL5rKq+vTVE/7Wgeo9Jgv0pkJ1HkAH40AMw59Ga8Zae93pC5+WXkUaSHtiqVA== X-Received: by 10.55.157.138 with SMTP id g132mr804587qke.313.1484708855129; Tue, 17 Jan 2017 19:07:35 -0800 (PST) Received: from [10.0.20.229] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id b34sm5383478qtb.46.2017.01.17.19.07.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Jan 2017 19:07:33 -0800 (PST) From: Ted Lemon Message-Id: <93F57527-1593-4876-A810-69C390E75D88@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_53692BEB-51B9-4ECC-8F3E-FC5A2BA9AFD2" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Tue, 17 Jan 2017 22:07:32 -0500 In-Reply-To: To: Mark Smith References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <6f3241eb-9d47-0a6e-7c0d-e9b5a69b86d0@si6networks.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: Fernando Gont , IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 03:07:37 -0000 --Apple-Mail=_53692BEB-51B9-4ECC-8F3E-FC5A2BA9AFD2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jan 17, 2017, at 9:48 PM, Mark Smith wrote: > I would like Android to have a stateless DHCPv6 implementation, so > parameters such as DNS, NTP, timezone etc. can be set on it. Why would you trust an unauthenticated local network service to = configure your phone's NTP server and timezone? --Apple-Mail=_53692BEB-51B9-4ECC-8F3E-FC5A2BA9AFD2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Jan 17, 2017, at 9:48 PM, Mark Smith <markzzzsmith@gmail.com> wrote:
I would like = Android to have a stateless DHCPv6 implementation, so
parameters such as DNS, NTP, timezone etc. can = be set on it.

Why would = you trust an unauthenticated local network service to configure your = phone's NTP server and timezone?

= --Apple-Mail=_53692BEB-51B9-4ECC-8F3E-FC5A2BA9AFD2-- From nobody Tue Jan 17 19:43:53 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B899129622 for ; Tue, 17 Jan 2017 19:43:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 VbdL231kdjjD for ; Tue, 17 Jan 2017 19:43:50 -0800 (PST) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD740128B37 for ; Tue, 17 Jan 2017 19:43:50 -0800 (PST) Received: by mail-vk0-x233.google.com with SMTP id r136so712483vke.1 for ; Tue, 17 Jan 2017 19:43:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fqb5dBxcMLEI3vZ8UGLeJUs5EtkH4cqi6Aw+xjeeLZY=; b=ao+7YXpKxCP7xVbJvXNQ61wXBIJtYFWRnFUjv687MNukkqR5ZFyFzimVKqaYMIQ5XJ LIswpLHQdVNDLzFPakK1aK7qA0IFv3pnWmG1PYl3J2aoJl4fD83qgfFfEXusBshRWfz3 XE5K3GOVFliKO2S8AqZa0b58OVcmyqEnCgthrlsIF7A6ws2av39eNNwWeB52U6kP/i3U cAbVEtzeeCTqqLoLFzl0zAyupuD7W6d4/Ysn48a2kjimtqmTQJYCzmAszP13Pk6acM0R Q3XtBmooRYJdcUPK9Sdg8wyIrWHGeY7DYbIzdMqsAvUI6vQW1ZnxPA7vW0dyvqOBbsz7 6D1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fqb5dBxcMLEI3vZ8UGLeJUs5EtkH4cqi6Aw+xjeeLZY=; b=Hw4j1PxgrSZQuOdZ9StjUw3yAg42QRZ0/PGGxV7QDqCRxGKjSBVUQTUEgozRyhF0F1 NBWycQj2B6XCmkOS1lRThd6LUBeEzWkz9VL1LL3cvkuGL0TCBnJf4Zah69mMmRsh2NnC SKtj61zYbCd8Dr6GMsY6lDUJiTfeL9Iotlw663l0cT4Q208R4IQ+qRZN2pbuRBB9b4S/ SbFeFiFAroV7HHSCVsQn2druv3UUkjeJos2bLHtjyND3s2Q38za2SlQkKWOSm7JRNxAg ZJH6Y6sXE17aB4yphwLfbGgkSma5tN/ZndzzNrb7lylgS8d/Kkceb9FJ9KO3czXnmYV9 yesA== X-Gm-Message-State: AIkVDXKo/T6aWRhhvqdlKxHP6usM+Peo+XdYcERvsOrn44+BTm2J98jXq5KEAmyWOK6UO9ZmdKp/hL7OTnrrcw== X-Received: by 10.31.79.132 with SMTP id d126mr560126vkb.165.1484711029856; Tue, 17 Jan 2017 19:43:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.2.235 with HTTP; Tue, 17 Jan 2017 19:43:49 -0800 (PST) Received: by 10.176.2.235 with HTTP; Tue, 17 Jan 2017 19:43:49 -0800 (PST) In-Reply-To: <93F57527-1593-4876-A810-69C390E75D88@fugue.com> References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <6f3241eb-9d47-0a6e-7c0d-e9b5a69b86d0@si6networks.com> <93F57527-1593-4876-A810-69C390E75D88@fugue.com> From: Mark Smith Date: Wed, 18 Jan 2017 14:43:49 +1100 Message-ID: To: Ted Lemon Content-Type: multipart/alternative; boundary=001a114dd4cc87611f0546563993 Archived-At: Cc: Fernando Gont , v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 03:43:52 -0000 --001a114dd4cc87611f0546563993 Content-Type: text/plain; charset=UTF-8 On 18 Jan. 2017 14:07, "Ted Lemon" wrote: On Jan 17, 2017, at 9:48 PM, Mark Smith wrote: I would like Android to have a stateless DHCPv6 implementation, so parameters such as DNS, NTP, timezone etc. can be set on it. Why would you trust an unauthenticated local network service to configure your phone's NTP server and timezone? Some networks I would trust to set that, others I wouldn't. Trusting mobile networks to set that can be an issue; my home town is one of the two places in the world with a 1/2 hour timezone, and every few years they seem to send out bad time for a while, usually at around the daylight savings cut over. When I'm at home I'd like to have my phone use my NTP server over other sources time sources I don't operate. Accessing an external service provides them with identity and other information for the transaction even if it is valid for a relatively short period of time (e.g. temporary addresses used to access a NTP service on the Internet). Being able to use a locally operated version of that service mitigates that. Regards, Mark. --001a114dd4cc87611f0546563993 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 18 Jan. 2017 14:07, "Ted Lemon" <mellon@fugue.com> wrote:
On Jan 17, 2017, at 9:48 PM, Mar= k Smith <mar= kzzzsmith@gmail.com> wrote:
I would like Android to have a stateles= s DHCPv6 implementation, so
parameters such as DNS, NTP, timezone etc. can be set on it.

Why would you trust an unauthenticated local = network service to configure your phone's NTP server and timezone?
=

Some networks I would trust to set that, others I wouldn= 9;t.

Trusting mobile networks to set that can be an iss= ue; my home town is one of the two places in the world with a 1/2 hour time= zone, and every few years they seem to send out bad time for a while, usual= ly at around the daylight savings cut over. When I'm at home I'd li= ke to have my phone use my NTP server over other sources time sources I don= 't operate.

Accessing an external service provides = them with identity and other information for the transaction even if it is = valid for a relatively short period of time (e.g. temporary addresses used = to access a NTP service on the Internet). Being able to use a locally opera= ted version of that service mitigates that.

Regards,
Mark.

--001a114dd4cc87611f0546563993-- From nobody Tue Jan 17 21:24:59 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67EA012944B for ; Tue, 17 Jan 2017 21:24:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 tXl_lM7NRYWa for ; Tue, 17 Jan 2017 21:24:57 -0800 (PST) Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EC32129404 for ; Tue, 17 Jan 2017 21:24:57 -0800 (PST) Received: by mail-pg0-x229.google.com with SMTP id 194so1309364pgd.2 for ; Tue, 17 Jan 2017 21:24:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=g3spaa0MrTtl9XM1hSn+PcZIy6jGJDaJXzu9EX4iNKg=; b=qtt9r79qJeZoxRIwXxjoyjzJ7OjJttMy6JZxNuQtav+XI8Dar+KgV9G6c7/Vps5Mxb g+q3gKddD9kvfI6ZPR7ubLOjDrebaEBUz7RdtGRttVuEII0Un54JrXKRHvdodAIENUsN rycBjg5ARyVqsIJ+22W9u1jHESSGoXEPI0MoB99cj/iZKlEZ4v4SaB0QrtMH/sInnyjA PFv+Y/33H14dupfcuuivTRNG8MVk9nJYmKkzmeMqD3fAfiEEcBUpvUYPPFx/zL/3g0Xn 1V1v0Cvn1eLg06Hp1BAcUGSFpOMS5r2/d/qC4+g4DYEdZs4rzjRTMMz4nfdVdh097CND j+Gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=g3spaa0MrTtl9XM1hSn+PcZIy6jGJDaJXzu9EX4iNKg=; b=AOO+JI+MCdAKOSiKAyDYjoMsSxGxsWGCixJPqYSk5M0dBOpEwcEgEdjbTKD+pEiYOx lYH4AP+gmDZTXIrhHCQn6Sp6QmmOgEh2EUAUfR/M1ukbmWSI9/DKUJjZD5F/ELYyKijp caqkieTHfgLsB+h6q43Vifo8RRddJCNwkCeo49IRWOo9/SpVy6F53ON+VMc9NcjObIJ0 rc16zuurJekLOs/AcrAFM2D/ldG6nooLuHSx9CB7ApCY5+Ah4GEhbGLqKTqnb06+Lwat Z/kC/juNhCpwsQeKHWN54LKOuYYSbdJfYvyfPPog+dxVK9Nc8Wp1e6HTCP9esvgDJ6hE nIQA== X-Gm-Message-State: AIkVDXKVaXnG3IzVVvn0XmvbNWoe1zby7Y32ntUuubgpMfL3mnmrTX8LKUzTyEpoQmUTQw== X-Received: by 10.98.26.210 with SMTP id a201mr1698158pfa.57.1484717096665; Tue, 17 Jan 2017 21:24:56 -0800 (PST) Received: from [192.168.1.15] (wsip-184-191-158-59.sd.sd.cox.net. [184.191.158.59]) by smtp.gmail.com with ESMTPSA id j130sm60170886pgc.2.2017.01.17.21.24.55 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Jan 2017 21:24:55 -0800 (PST) From: Fred Baker Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Message-Id: Date: Tue, 17 Jan 2017 21:24:55 -0800 To: v6ops list X-Mailer: Apple Mail (2.3259) Archived-At: Subject: [v6ops] Children, children X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 05:24:58 -0000 Come on folks, we're adults and professionals. If you want to take jabs = at each other, take it out in the street. In this context, let's focus = on professional, respectful discourse. Disagree all you like; don't be = disagreeable.= From nobody Tue Jan 17 23:05:08 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0A1D1293FE for ; Tue, 17 Jan 2017 23:05:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 vetBvoyIoMOf for ; Tue, 17 Jan 2017 23:05:05 -0800 (PST) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B923129458 for ; Tue, 17 Jan 2017 23:05:05 -0800 (PST) Received: by mail-vk0-x22f.google.com with SMTP id k127so2733507vke.0 for ; Tue, 17 Jan 2017 23:05:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1ze5wipoxkoRgd1k/1J1vrrywETsHmx/HNHrBUq1cAI=; b=MxwU5Z46jY2KwGXmkMPosZEI3LFvAIuqfKODcvNo/zRMD/HiAmKfgBs5nqTjKk4bT2 uPEFRbvPWm4kkQ1+NIfuoZfVKJSP7JMjc8mut5HnvR3I6jJWGHgQNnc/6UNA8sV9FiH1 M71JI2Jami4y5GKzP3lGj3hRg5FHo3VXfax76hUFbZw/eNHXMkYpo8QnTDpaG/5QPl/V 4vbRlAdl/2WD3E8BIY/Joqmdek1jjUv8yBFxhjxXzzocZKhma//moIuxQC6wE+z0kdn3 X79LYc0w2UiCSUwcynk4pGshEee4hzMF/FFRwk8nk5cbzU+IBRkfqCdBOfO9NZYEIppY tTog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1ze5wipoxkoRgd1k/1J1vrrywETsHmx/HNHrBUq1cAI=; b=oDa34K8+USVwU8SQpOoEu8ql3UYBZMYKUe07376s9SG15MXd680dXxWwzP2CtinXY6 9VkFumM2UNW+iVygVmG5GvuPrxP0RNUMg4Z+i1HyMHPOydt2vK6efFP24JlMVArZr6BA UZuqDlFz2F7YFLVT9j3wfeCtdJ6/Y6a4BzCjLfzLQAXlXxfrRE/Bc6QPkFQD98ntR3f4 gWiUcaeDhO5hpnmjkKi8bz6M4J/wf4yYO9RpKUG46xRorZfSAzowIAJmtq7OjjJHTCK3 fqjAvrqA39RSXMan44LQiSTzINl6ELtCNjlL+iYFFkilX6nxhkF1zPaAdRZiqbHyxRqA aBQw== X-Gm-Message-State: AIkVDXJYL++EmVS1/sM6NSJbH9TJDEFbVhSXDogNz7E9bypiNS9ZGUWJag7sh7Qv9GE2T+vgO9z+3q+Cbsy/hu8s X-Received: by 10.31.170.15 with SMTP id t15mr816952vke.6.1484723104120; Tue, 17 Jan 2017 23:05:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.171.2 with HTTP; Tue, 17 Jan 2017 23:04:43 -0800 (PST) In-Reply-To: References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> From: Lorenzo Colitti Date: Wed, 18 Jan 2017 16:04:43 +0900 Message-ID: To: Mark Smith Content-Type: multipart/alternative; boundary=001a1143225036565105465909dc Archived-At: Cc: Fernando Gont , IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 07:05:06 -0000 --001a1143225036565105465909dc Content-Type: text/plain; charset=UTF-8 On Wed, Jan 18, 2017 at 2:33 AM, Mark Smith wrote: > The generation after will learn both IPv4(+NAT) and IPv6. They'll just > accept more than one layer 3 protocol is necessary and that they work > differently, as my generation did when we ran IPv4 as well as IPX, > Appletalk etc. They'll do IPv6 the IPv6 way. > > This "IPv4+NAT only" generation will only last for a short period in > the life of IPv6. We should be careful not to hobble IPv6 to suit > their relatively limited world view. > Couldn't agree more. I think it falls on those of us who do have a more expanded world view, and who are more familiar with IPv6, to point out the advantages brought by that model and to avoid hobbling that model to match a worldview that evolved to support a protocol with different characteristics. > > > So in that respect, at this point, > > rather than fighting over a specific way to configure hosts (with the > > current outcome of "you have to do both!"), I'd probably try to make > > things easier/simpler for folks deploying v6, give them the two > > protocols as fully-working *options*, and let them decide by themselves > > whatever works better for them. > ... except that when you do that, inevitably some percentage of the population ends up choosing the familiar choice, and there's a risk that all implementations collapse to the lowest-common denominator. Example: just yesterday we were talking to colleagues who were implementing and showcasing an SDN controller for use on client networks. There was a desire to support both IPv4, dual-stack, and IPv6-only with NAT64. It turned out that the design of the system did not allow creating a neighbour cache entry (or ARP cache entry) on the basis of a data packet sent to a given IP address. The only way that the network could communicate with a new IP address was if that IP address had previously sent a control packet - specifically, a DHCPv4 or DHCPv6 request. They decided to do this in IPv6 based on the observation of DAD packets, but of course, that's not reliable. We told them that a router must fundamentally have the ability to learn ARP/ND cache entries without snooping because that behaviour is specified by the standards. We also explained that SLAAC allows hosts to create new addresses at any time, that current hosts do this to create new privacy addresses, and that this provides many benefits. Those arguments carried no weight; their response was, "why can't we just use DHCPv6". In the end, the argument that convinced them to implement ND cache learning (which, obviously a fundamental part of how ND works) was that Android would does not support DHCPv6, and they wanted to support Android. I think we need to recognize the fact that current implementations, even in IPv4, are based on assertions that are fundamentally coupled to the current IPv4 way of doing things. Technically, the design was incorrect even in IPv4, because even in IPv4 the routers are supposed to be able to send ARP requests for unknown IPv4 addresses. But because IPv4 is virtually only deployed with DHCP these days, they chose not to support anything else. --001a1143225036565105465909dc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jan 18, 2017 at 2:33 AM, Mark Smith <markzzzsmith@gmail.com&g= t; wrote:
The generation after wil= l learn both IPv4(+NAT) and IPv6. They'll just
accept more than one layer 3 protocol is necessary and that they work
differently, as my generation did when we ran IPv4 as well as IPX,
Appletalk etc. They'll do IPv6 the IPv6 way.

This "IPv4+NAT only" generation will only last for a short period= in
the life of IPv6. We should be careful not to hobble IPv6 to suit
their relatively limited world view.

Co= uldn't agree more. I think it falls on those of us who do have a more e= xpanded world view, and who are more familiar with IPv6, to point out the a= dvantages brought by that model and to avoid hobbling that model to match a= worldview that evolved to support a protocol with different characteristic= s.

> So in that respect, at this point,
> rather than fighting over a specific way to configure hosts (with the<= br> > current outcome of "you have to do both!"), I'd probably= try to make
> things easier/simpler for folks deploying v6, give them the two
> protocols as fully-working *options*, and let them decide by themselve= s
> whatever works better for them.

=
... except that when you do that, inevitably some percentage of the po= pulation ends up choosing the familiar choice, and there's a risk that = all implementations collapse to the lowest-common denominator.
Example: just yesterday we were talking to colleagues who were= implementing and showcasing an SDN controller for use on client networks. = There was a desire to support both IPv4, dual-stack, and IPv6-only with NAT= 64.

It turned out that the design of the system di= d not allow creating a neighbour cache entry (or ARP cache entry) on the ba= sis of a data packet sent to a given IP address. The only way that the netw= ork could communicate with a new IP address was if that IP address had prev= iously sent a control packet - specifically, a DHCPv4 or DHCPv6 request. Th= ey decided to do this in IPv6 based on the observation of DAD packets, but = of course, that's not reliable.

We told th= em that a router must fundamentally have the ability to learn ARP/ND cache = entries without snooping because that behaviour is specified by the standar= ds. We also explained that SLAAC allows hosts to create new addresses at an= y time, that current hosts do this to create new privacy addresses, and tha= t this provides many benefits. Those arguments carried no weight; their res= ponse was, "why can't we just use DHCPv6".

In the end, the argument that convinced them to implement ND cache l= earning (which, obviously a fundamental part of how ND works) was that Andr= oid would does not support DHCPv6, and they wanted to support Android.

I think we need to recognize the fact that current imp= lementations, even in IPv4, are based on assertions that are fundamentally = coupled to the current IPv4 way of doing things. Technically, the design wa= s incorrect even in IPv4, because even in IPv4 the routers are supposed to = be able to send ARP requests for unknown IPv4 addresses. But because IPv4 i= s virtually only deployed with DHCP these days, they chose not to support a= nything else.
--001a1143225036565105465909dc-- From nobody Tue Jan 17 23:16:46 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A03C129430 for ; Tue, 17 Jan 2017 23:16:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 OdsOVvSHT-ve for ; Tue, 17 Jan 2017 23:16:42 -0800 (PST) Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5F28128B44 for ; Tue, 17 Jan 2017 23:16:41 -0800 (PST) Received: by mail-ua0-x233.google.com with SMTP id 96so3281311uaq.3 for ; Tue, 17 Jan 2017 23:16:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=aL+3eCz9uCnskcBDMI1pF6Cir8rCkmD3uPL3j+JyLoE=; b=ALRkCrkwJYpcsRBV/Xbk8rZp05bviHpkV/z+vO5trgWilTprFNxgqBbK9CwfVM6/Qt QTAmdcVKl33gmisrZTCngt4RpLK61vh9uM2f5q3SAgbF2MdL83YXkMLz0fGBIpAePagY 1r+9Hr0AdvNaxtzfBFYNvxEmMLoI+7NH0NdSipGwIU5IZm7qWhEie63jvVYVKUZToilk G+exbZM5La/g4IO4gK1iTpFb+pMBnelGSAVVV1W1nuk30e51yOsPbPXNs8mcA3bFI38q 1xoyKn4bDJjvTHKLMs2iLwDN5gGCQz/zAUmliDnEYUh6nQclprGd4Pz5JjFR8c1tsu9m k/ZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=aL+3eCz9uCnskcBDMI1pF6Cir8rCkmD3uPL3j+JyLoE=; b=dlW2eF8/TvoBt5R9KMw6epxBYNlrCTb+V5s666YCvC1YA/PqqwyL/B3gj6w7bu9Myu 5wlQwIjUn13XTWmUip8WtYFNONOqyQJRQjVmCWsgfdE1qibJxvOhS1e84wa6wvmPObnd uVUH97gNNWgbZPIVyDuqRzp4yj1c4Dh68cI9o+ezAPkDBJtckcI8SzckdOBy1ajnmaYp 9mnMI+/EDHpAwteWpJ+gl14+TUwePRI6MgXj+w404VnmItHcexLsey8BdEXO1Pg8H0bs mgiuPHRW2m1/lyVEGYtHEa0B3qahWBSe2kdE8orSrieR/U+gSlGCpuWqWWfyAuuVSecC xhBQ== X-Gm-Message-State: AIkVDXK5IbQMOy8JLXO/YaDpXVj3TsHZQon5IWGdxAYMGVmUgabdudvyHp1bKz1EWedlKV/vSaHxd5CD2xYIQEMr X-Received: by 10.159.40.194 with SMTP id d60mr1098483uad.122.1484723800539; Tue, 17 Jan 2017 23:16:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.171.2 with HTTP; Tue, 17 Jan 2017 23:16:19 -0800 (PST) In-Reply-To: References: <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <20170117.170305.74705723.sthaug@nethelp.no> From: Lorenzo Colitti Date: Wed, 18 Jan 2017 16:16:19 +0900 Message-ID: To: Mark Smith Content-Type: multipart/alternative; boundary=94eb2c1245beb8e66405465932e4 Archived-At: Cc: Fernando Gont , v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 07:16:43 -0000 --94eb2c1245beb8e66405465932e4 Content-Type: text/plain; charset=UTF-8 On Wed, Jan 18, 2017 at 1:52 AM, Mark Smith wrote: > DHCPv6 is more capable, flexible and general purpose. > In many ways it actually isn't more capable. In particular, - It is very difficult or impossible to change anything. In theory, there's reconfigure. In practice, nobody implements that, even when it is mandatory. (In the immortal words of Steven Barth, lead OpenWRT developer, "home gateways are supposed to MUST" implement reconfigure.) In contrast, RAs are fundamentally dynamic. - It is very difficult to have multiple sources of information. In theory it's possible to get multiple OFFERs and select more than one of them, but I think common clients don't implement this. - It is impossible to add a new source of information once the client has a lease, because there's no push mechanism. Even if reconfigure were implemented, which it isn't, only the original server can reconfigure because it's the only one that the client trusts. RAs - If the server crashes or is unplugged, there is no way to update the client because only the server can reconfigure the client. All these make DHCPv6 a rather bad idea for networks that change without advance warning, such as home networks. The only reason we don't have these problems in IPv4 is that in IPv4 we have NAT (which means the clients never need to change their IP address on demand) and VRRP. It would be nice not to need NAT, at least. --94eb2c1245beb8e66405465932e4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jan 18, 2017 at 1:52 AM, Mark Smith <markzzzsmith@gmail.com&g= t; wrote:
DHCPv6 is more capable, = flexible and general purpose.

In many w= ays it actually isn't more capable. In particular,
  • It= is very difficult or impossible to change anything. In theory, there's= reconfigure. In practice, nobody implements that, even when it is mandator= y. (In the immortal words of Steven Barth, lead OpenWRT developer, "ho= me gateways are supposed to MUST" implement reconfigure.) In contrast,= RAs are fundamentally dynamic.
  • It is very difficult to have multip= le sources of information. In theory it's possible to get multiple OFFE= Rs and select more than one of them, but I think common clients don't i= mplement this.
  • It is impossible to add a new source of information = once the client has a lease, because there's no push mechanism. Even if= reconfigure were implemented, which it isn't, only the original server= can reconfigure because it's the only one that the client trusts. RAs= =C2=A0
  • If the server crashes or is unplugged, there is no way to up= date the client because only the server can reconfigure the client.
All these make DHCPv6 a rather bad idea for networks that chan= ge without advance warning, such as home networks.

The only reason we don't have these problems in IPv4 is that in IPv4 w= e have NAT (which means the clients never need to change their IP address o= n demand) and VRRP. It would be nice not to need NAT, at least.
=
--94eb2c1245beb8e66405465932e4-- From nobody Tue Jan 17 23:36:52 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 667CE128B44 for ; Tue, 17 Jan 2017 23:36:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.4 X-Spam-Level: X-Spam-Status: No, score=-7.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 PC1ATSsH7YoJ for ; Tue, 17 Jan 2017 23:36:48 -0800 (PST) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with ESMTP id 807BE120727 for ; Tue, 17 Jan 2017 23:36:48 -0800 (PST) Received: from localhost (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by bizet.nethelp.no (Postfix) with ESMTP id 0F76BE6065; Wed, 18 Jan 2017 08:36:46 +0100 (CET) Date: Wed, 18 Jan 2017 08:36:45 +0100 (CET) Message-Id: <20170118.083645.74703822.sthaug@nethelp.no> To: lorenzo@google.com From: sthaug@nethelp.no In-Reply-To: References: <20170117.170305.74705723.sthaug@nethelp.no> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 07:36:50 -0000 > - It is very difficult to have multiple sources of information. In > theory it's possible to get multiple OFFERs and select more than one of > them, but I think common clients don't implement this. Having multiple OFFERs is normal if you run DHCPv4 with failover. Yes, a small percentage of clients have problems. Most of them don't. Steinar Haug, AS2116 From nobody Tue Jan 17 23:47:20 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13685129622 for ; Tue, 17 Jan 2017 23:47:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 0N2ppW1OVVqS for ; Tue, 17 Jan 2017 23:47:17 -0800 (PST) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F318129430 for ; Tue, 17 Jan 2017 23:47:17 -0800 (PST) Received: by mail-ua0-x235.google.com with SMTP id i68so3760757uad.0 for ; Tue, 17 Jan 2017 23:47:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=foORGDRZ3trBT9IvOeWSF00TMbpAcXiRYrVKRF9s6CY=; b=dKWHILgw67x7KSQ7ZxB43pgng5oXwP2nFxDRffOVEyUQE0IGWPu1fu+IvSs9kvyOKx 17UEniDO6Pa05pLxG1BfzLqMRi2GMPd2x5bl14mNc9yFGZacAXfZapof0f9UaixA0/wk TQcCK1ETBplM6R4QV/m3N9gF40WqjBESnfT8YF8+iqMsAP0yplCL2x4wbgM6Z+4GNrSN SL2zbbZk+f7GrcPUNj4PSaKoe5NMvwdbJzgFgTsiTOUqPtcC3Xx1B9LeGa+97d3MATGW iQaMuuLkqfkZSjgbY3TshFWY2oNgNrv+ztyEDKpRfDGJS5wDq3HXHmkRZX0fPLzyJPP/ 77ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=foORGDRZ3trBT9IvOeWSF00TMbpAcXiRYrVKRF9s6CY=; b=fPyQsNmMDVnr6ABr1eEzSObNspap7EyJCpqYCVLD1ohz9Gs6B3/P3IyhtubYWPzU2I IiSF/HgwEUIBI/ZctjmOGHs5QHkS7AUPG3WLhEnwbugwl6jFtgO1VpwWQ+LzO/G8Fbgk RMbcj8HoJFIcas1FQPyzNA8PqGfzsJWszwCDgxDLE68bPDSlCmdHk/qqJKVGz39n2OaH 6kLn5/w55yd2K7loGWF/8rRIG+/a/b8ekaWxHUHVYhPzL6Zb6uwkhFR3G4j/h7M5v02B LOlm+u56vTHcn5mxRf36IbFxl/Ae/ITaP2wqcqbRO/3H7JZBypenRSMolnQEIKH79mxV 1trA== X-Gm-Message-State: AIkVDXL0VEqg/1VSHg/15VUd6E1xU9Jxtv7Kxv/VOLiCmwBAEC/Fd1qXy43S5rl0JJymFMD8BPCpFUcEcbHvbH8v X-Received: by 10.159.41.198 with SMTP id s64mr1156035uas.72.1484725636149; Tue, 17 Jan 2017 23:47:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.171.2 with HTTP; Tue, 17 Jan 2017 23:46:55 -0800 (PST) In-Reply-To: <20170118.083645.74703822.sthaug@nethelp.no> References: <20170117.170305.74705723.sthaug@nethelp.no> <20170118.083645.74703822.sthaug@nethelp.no> From: Lorenzo Colitti Date: Wed, 18 Jan 2017 16:46:55 +0900 Message-ID: To: sthaug@nethelp.no Content-Type: multipart/alternative; boundary=001a1148d93a221079054659a0b5 Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 07:47:19 -0000 --001a1148d93a221079054659a0b5 Content-Type: text/plain; charset=UTF-8 On Wed, Jan 18, 2017 at 4:36 PM, wrote: > > - It is very difficult to have multiple sources of information. In > > theory it's possible to get multiple OFFERs and select more than one > of > > them, but I think common clients don't implement this. > > Having multiple OFFERs is normal if you run DHCPv4 with failover. Yes, > a small percentage of clients have problems. Most of them don't. > The fact that the client gets multiple OFFERs is irrelevant. What matters is whether it can accept more than one of them. IIRC in DHCPv4, this is not possible at all, because the client signals acceptance of a particular address by broadcasting a REQUEST, and that REQUEST implicitly declines all the other OFFERs. In DHCPv6 it might be possible, but even if it is, I doubt that common clients implement it. --001a1148d93a221079054659a0b5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jan 18, 2017 at 4:36 PM, <sthaug@nethelp.no> wrote:
=
>=C2=A0 =C2=A0 - It is very difficult to = have multiple sources of information. In
>=C2=A0 =C2=A0 theory it's possible to get multiple OFFERs and= select more than one of
>=C2=A0 =C2=A0 them, but I think common clients don't implement this= .

Having multiple OFFERs is normal if you run DHCPv4 with failover. Ye= s,
a small percentage of clients have problems. Most of them don't.

The fact that the client gets multiple OFFERs= is irrelevant. What matters is whether it can accept more than one of them= . IIRC in DHCPv4, this is not possible at all, because the client signals a= cceptance of a particular address by broadcasting a REQUEST, and that REQUE= ST implicitly declines all the other OFFERs.

In DH= CPv6 it might be possible, but even if it is, I doubt that common clients i= mplement it.
--001a1148d93a221079054659a0b5-- From nobody Wed Jan 18 06:11:01 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E74E91297C5 for ; Wed, 18 Jan 2017 06:10:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 IxGhOmHbSZtN for ; Wed, 18 Jan 2017 06:10:58 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6BB61297BF for ; Wed, 18 Jan 2017 06:10:57 -0800 (PST) Received: from pps.filterd (m0049462.ppops.net [127.0.0.1]) by m0049462.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v0IE4peV014254; Wed, 18 Jan 2017 09:10:56 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049462.ppops.net-00191d01. with ESMTP id 281wryjq7a-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 18 Jan 2017 09:10:56 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v0IEAt3k019445; Wed, 18 Jan 2017 09:10:55 -0500 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v0IEAm1c019387 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 18 Jan 2017 09:10:49 -0500 Received: from GAALPA1MSGHUBAB.ITServices.sbc.com (GAALPA1MSGHUBAB.itservices.sbc.com [130.8.218.151]) by alpi132.aldc.att.com (RSA Interceptor); Wed, 18 Jan 2017 14:10:40 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.67]) by GAALPA1MSGHUBAB.ITServices.sbc.com ([130.8.218.151]) with mapi id 14.03.0319.002; Wed, 18 Jan 2017 09:10:40 -0500 From: "STARK, BARBARA H" To: Mark Smith , Fernando Gont Thread-Topic: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem Thread-Index: AdJsHl8eSkgq9pmdSH+a6rrO1byUfgEFygGAAA8QH4AABHryAAAFi+6AABamyQAAAefeAAABY7CAAADtOoAADXFtAAAWNOGA Date: Wed, 18 Jan 2017 14:10:39 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DA941D1@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <6f3241eb-9d47-0a6e-7c0d-e9b5a69b86d0@si6networks.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.233.99] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-01-18_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1701180192 Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 14:11:00 -0000 > So the problem used to justify RDNSS was that a stateless DHCPv6 client w= as > too heavy weight for low powered / embedded devices. That sounded > reasonable at the time, however the more I've since thought about it, the > more I think that justification is false. If a device doesn't have the re= sources > to implement a stateless DHCPv6 client (i.e., implement just the parts of= the > DHCPv6 protocol required to handle parameters, but not address > assignment/IA_* options), then it probably is too low end to be > implementing IPv6. CPU and memory is always getting increasingly cheaper. There is a large movement for very constrained IoT devices to only support = IPv6 (no IPv4).=20 Barbara From nobody Wed Jan 18 10:30:58 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00119129401 for ; Wed, 18 Jan 2017 10:30:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 FtULtGL9zzoO for ; Wed, 18 Jan 2017 10:30:55 -0800 (PST) Received: from mail-yw0-x243.google.com (mail-yw0-x243.google.com [IPv6:2607:f8b0:4002:c05::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F2A3120725 for ; Wed, 18 Jan 2017 10:30:55 -0800 (PST) Received: by mail-yw0-x243.google.com with SMTP id v73so1802610ywg.1 for ; Wed, 18 Jan 2017 10:30:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=8jz27rNalbyT53SUKtmqVnEJ9Lm2tllUm7KWUsnM+Uo=; b=vgYVMIzNMz0c3aiuCAJSKnFG2RZe2BUtrGZb9bahNPYbA7GUbQ9/BZbUXjtzRx6oEL J+3PvPSvdOdzQmTI6ax4K1k4pnByCmXFOO4ksV1OtMJ9U5yYWCnH6lAdloXCT1JNGTug z3/s0IdabMbPMyzI4Q47dTmGqtWO9O04dTSpZ/2ShYmdXAyfhJl/FRr7aP2ro0dBnu93 wZZCiSzt0FHXRcI1/nUrOjHZGnBi1aKGIO/27XHjxwTb/oGS37RRaRnvS9AEFNuDT02N 4pRzg9CT13xld+FiO+j8yUuHYYtik0ZNfCP+KvdNR9UPmOt6nphdcqL0dNxnTt70S3Av 4XKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=8jz27rNalbyT53SUKtmqVnEJ9Lm2tllUm7KWUsnM+Uo=; b=ErCz10Q0tojXKMAoUZNQP69IWgh2Qkizl520hRfw64Kczk2uexE2HNTVgU9r7TqNbF /EXdvG4q4JSbde89hPb+ordWHSeoA4RktY8r0uNolzt+pTAznV8sTxZkw34wUBrN46zg EC1ZaX8pJJLFZhMl0DoZvXmNF5xG+fKZ0+vdHxDpIuXxhTBDHGF78lQ7LwzQQ/Wj1iYA E97azCLTizoSVk5XxiMOujU4eEcyi6tXMHIXTI2mGa+VaF0jUuawT7jqZMhWtZgUN21V J6c14hDnUa78W4cV6EbkbLGODXw+kZafHXgHdxqaLlGipy+II5TKK++bVA42yLHlWJDY VSEA== X-Gm-Message-State: AIkVDXJDrXwB/c5oJZ6yQkKtTdfW500fHvoVkMmoYsc0fYGWvxK4qUOUpLNjq4ZnZlWuTeiyd2zP6ANo4ZtGtg== X-Received: by 10.55.123.129 with SMTP id w123mr4245893qkc.20.1484764254677; Wed, 18 Jan 2017 10:30:54 -0800 (PST) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.29 with HTTP; Wed, 18 Jan 2017 10:30:54 -0800 (PST) In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F45C2E986B1@nkgeml514-mbx.china.huawei.com> References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2E981DF@nkgeml514-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2E986B1@nkgeml514-mbx.china.huawei.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Wed, 18 Jan 2017 10:30:54 -0800 X-Google-Sender-Auth: LckFgv9XAAf2a6wLwVJBdqQCjac Message-ID: To: "Liubing (Leo)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IPv6 Ops WG , "v6ops-chairs@tools.ietf.org" Subject: Re: [v6ops] Possible consensus of dhcpv6-slaac-problem draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 18:30:57 -0000 At Wed, 18 Jan 2017 02:45:38 +0000, "Liubing (Leo)" wrote: > Personally, one of the main issues of dhcpv6-slaac-problem is not about behavior-only vs problem description, but that it talks about > (seemingly) random topics most of which don't seem (to me) to have practical importance. > [Bing] I don't quite understand what you said "random topics" mean. This document is actually focusing on a very specific topic - the ambiguity of the M/O flags, and the divergent behaviors caused by the ambiguity. > We had a (as much as we could did) comprehensive analysis of the > ambiguity possibilities from the early versions drafts. And we > observed divergence on each of the possibilities. So, personally I > don't think the draft is discussing something randomly. I meany by "randomly" that it consists of important and non-important divergent behaviors. I thought I specifically explained these in my latest review comments for the draft. BTW, I guess trying to be "comprehensive" is actually one major reason why I cannot be so enthusiastic about the current content of the draft. IMO this exact attempt makes the draft look "random". > Of course, what is important and what is not is quite subjective, so it's not surprising if some other people consider most/all of the topics are important. > But my impression from the past and current discussion of the draft is that it's at least not only me. > [Bing] There were several people don't agree the "problems" discussed in this document were "really problems". I understand it is not easy to get consensus. > But I also have an impression that people in general think it's good to record and publish the ambiguity and the divergent behaviors. I don't deny some other people might think even just describing "random" behaviors is a good thing. I just personally disagree with that position, since it will result in a much less useful document after spending a lot of wg energy. IMO it's worse than not publishing it at all. > In this sense, just focusing on describing the random behaviors does not sound okay to me. > What I want to see is to have some level of consensus on what is important and practical and focus on them. > [Bing] As you said, what is important and what is not is quite subjective. So why not we just keep the objective fact and let the readers/administrators decide according to their specific situation. Again, I personally don't think it a good idea. But I'm just one ordinary wg participant without any vito power or anything. You don't necessarily have to convince me if you can reach a wg rough consensus without my support. If I were the author, I'd step back and focus on one obviously "important" point: coexistence of SLAAC and address assignment by DHCPv6 isn't possible in some cases, and very carefully add other points if and when we have a greater consensus that they are operationally important. But perhaps you'd rather be "comprehensive" and don't like the idea - in that case, I think we just have to agree to disagree. -- JINMEI, Tatuya From nobody Wed Jan 18 11:17:47 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31E5C120725 for ; Wed, 18 Jan 2017 11:17:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Uj19BU8O9Vtn for ; Wed, 18 Jan 2017 11:17:45 -0800 (PST) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2C4E129562 for ; Wed, 18 Jan 2017 11:17:44 -0800 (PST) Received: by mail-vk0-x22a.google.com with SMTP id r136so14817458vke.1 for ; Wed, 18 Jan 2017 11:17:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=07cDPecsgIix7bO3gNa+1ne8ufBYEGZdAgKJOWjoRfg=; b=A/BRhtvFCUKoe9/KDuIeaVtXhxHLQ7/IEyrVP+WtEC2zonhXBuUpNWY1S2Ke3Z45bQ +JpX0Tc3sr20y605cBJvH3xRvjvhB82vzvZiLJZI8hfipiB6VricZMVdK9swLUWllp1K l+SEiUqFC6liaixgBUuA0WkZc8c4WQJRnfsrEucRrGDuoL1jakGWnnV1L+wsILRMSmQf y2juw4DBbvnwxarEvsYQBcBQKke+IEJnSBdKpupGWfwyyvbybkiqH09oY1pnIztlk4IO Lh4+ou/P8E+tO1fVaWN56x/e11AXHJgJVytjjQM7+YHHNi5ABQtXyXl7T+kg2b3RxqfI MpqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=07cDPecsgIix7bO3gNa+1ne8ufBYEGZdAgKJOWjoRfg=; b=uMAA8V1przgtfKa5NjSbkpMO0sOlzEhviCmm4jGXZSxNfzJub3KiZkOehJmkR2dLGs T5OKvpLKq/JZgyKQ2m9CYbcYY92pMbD6Q40qpYc3EjJX0aYpWXDatSLm5hh+mZwAiGFC TlrS8qxHk6otbaG1HXGqi1KIunQ4PDddBR/wHIiAEk30I5WXeC5EUCzjiwFHSRl7RCPW zDoGp6rwmMP5x/4bXoVU/aI3SufclyL+6rby2xzmXZWAfBG115M2n+kUZr+rx9WLafIg 9xRyhmaowUl/QhU7pvXMcIPobhstQX4Jwi8HdsKYJ3MnPYXW9UJ2d/rfpBNPPnyOQ4jU V+fQ== X-Gm-Message-State: AIkVDXLtd2EFFj93hdc9sv5W56HMog4/wL78HnfeV9LWzspbIAXQBEYZiVwcqCPVloYbpajkN9+iUs79BtNAEg== X-Received: by 10.31.98.196 with SMTP id w187mr2038816vkb.169.1484767063887; Wed, 18 Jan 2017 11:17:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.2.235 with HTTP; Wed, 18 Jan 2017 11:17:13 -0800 (PST) In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DA941D1@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <6f3241eb-9d47-0a6e-7c0d-e9b5a69b86d0@si6networks.com> <2D09D61DDFA73D4C884805CC7865E6114DA941D1@GAALPA1MSGUSRBF.ITServices.sbc.com> From: Mark Smith Date: Thu, 19 Jan 2017 06:17:13 +1100 Message-ID: To: "STARK, BARBARA H" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Fernando Gont , IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 19:17:46 -0000 Hi, On 19 January 2017 at 01:10, STARK, BARBARA H wrote: >> So the problem used to justify RDNSS was that a stateless DHCPv6 client was >> too heavy weight for low powered / embedded devices. That sounded >> reasonable at the time, however the more I've since thought about it, the >> more I think that justification is false. If a device doesn't have the resources >> to implement a stateless DHCPv6 client (i.e., implement just the parts of the >> DHCPv6 protocol required to handle parameters, but not address >> assignment/IA_* options), then it probably is too low end to be >> implementing IPv6. CPU and memory is always getting increasingly cheaper. > > There is a large movement for very constrained IoT devices to only support IPv6 (no IPv4). > Barbara I wouldn't have even thought anybody would have been considering IPv4, as as far as I'm aware, all the work on resource constrained networks has been done for IPv6 (e.g., ROLL, 6lowpan groups etc.) The question is that if a host is so resource constrained that it can't run a stateless DHCPv6 client, is it actually capable of running a compliant IPv6 stack? I wouldn't think so, so I don't think the justification for RDNSS is really valid. Regards, Mark. From nobody Wed Jan 18 11:30:10 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8031129863 for ; Wed, 18 Jan 2017 11:30:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 QRjiJWuI0fh0 for ; Wed, 18 Jan 2017 11:30:07 -0800 (PST) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6D981297F7 for ; Wed, 18 Jan 2017 11:30:07 -0800 (PST) Received: by mail-pf0-x22a.google.com with SMTP id 189so6521506pfu.3 for ; Wed, 18 Jan 2017 11:30:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:message-id:mime-version:subject:date:references:to:in-reply-to; bh=2/cuNtiY88ji/cLe4w1zDXY+Cy8+sdVC7SosSyZcLD8=; b=NeLT+F23MNaFR3Y8xC695fb6/t1wYdtHIsiSfDTnWDFkOE1ryoe+H7+9F+BkGru99r khUbFuL8D3qFFOuh666B3o8gZFmggPbCEQcrHak8/vqHugpvGIbxRpFwCIMqG7gti1+b sXshFrxpINhqm0+uBWrxNGbjgoTcApMqnDD76oYJ1YihAh5ofQTgLLuobnNbMDXdwd3h rVKidAZ9zeIT2d5/cgs3g0nRgim5vapBpae+FiDJ+n1xGtEhjMLPCIpDiHFCTXhPdwe2 2Be8H6Bqkm3fdWDBB9uTJK8y4OwHykQGumBnQU6RFyjnhVlAaAH4kXMcTkAx0qsTiEsb 7xPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :references:to:in-reply-to; bh=2/cuNtiY88ji/cLe4w1zDXY+Cy8+sdVC7SosSyZcLD8=; b=BVfxrLOkqq9GXkUnXu9mOryTBQnQ9g6S5vCSoyncZhuoAv2ZLePTZfIVlGBmFlQBQe ZqmPRy6nnBskB+eAbUSoNRH9S8bodQYTTADdfcpvrwC3i1vP4WRAQUgy0GBH2i0qgzqT i6rauCoVNOplV0wNL+3rp/XnNX2tJ17nLQkWXMfkhsHyh5DXUEX513D15Svq3+B3s26K xWUGDXW5cCm7ICbv8qflcXEp86YWb5fMf4tsKu3eJnk+jhag1ZU1Q1YLTHXmkYffjk8H xDzY7OYG9rPg23GA7k84BiuF39XrewumL8/f1dH90eZsesJf8qObFsHCrdHxGzPR1fYD B5DQ== X-Gm-Message-State: AIkVDXJC9OSpA8Jf+NsCO5tRJj3G03/UnPpIms95Sm7tTut5zjS0A14vpFAscqyCEvHwoTuA X-Received: by 10.99.171.75 with SMTP id k11mr5849823pgp.16.1484767806894; Wed, 18 Jan 2017 11:30:06 -0800 (PST) Received: from dhcp-100-99-230-134.pao.corp.google.com ([100.99.230.134]) by smtp.gmail.com with ESMTPSA id z29sm2689909pgc.7.2017.01.18.11.30.06 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 18 Jan 2017 11:30:06 -0800 (PST) From: james woodyatt Content-Type: multipart/alternative; boundary="Apple-Mail=_6F437F8B-72D4-4EE8-843D-276F46C5D059" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Date: Wed, 18 Jan 2017 11:30:05 -0800 References: <67b3af77-3ab6-95f2-93c5-45d036efb935@bogus.com> To: IPv6 Operations In-Reply-To: X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-considerations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 19:30:09 -0000 --Apple-Mail=_6F437F8B-72D4-4EE8-843D-276F46C5D059 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jan 11, 2017, at 21:12, Lorenzo Colitti wrote: >=20 > There are no case studies in this document, and I am not aware of any = publicly-available operational reports of substantial ULA deployments. Reminder: Understanding Apple=E2=80=99s Back to My Mac Service [RFC = 6281]. --james woodyatt > --Apple-Mail=_6F437F8B-72D4-4EE8-843D-276F46C5D059 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Jan 11, 2017, at 21:12, Lorenzo Colitti <lorenzo@google.com> = wrote:

There are no case studies in this document, and = I am not aware of any publicly-available operational reports of = substantial ULA deployments.

Reminder: Understanding = Apple=E2=80=99s Back to My Mac Service [RFC 6281].

--james woodyatt <jhw@google.com>



= --Apple-Mail=_6F437F8B-72D4-4EE8-843D-276F46C5D059-- From nobody Wed Jan 18 16:14:33 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE56C1293FC for ; Wed, 18 Jan 2017 16:14:30 -0800 (PST) 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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 xdS50E6AeEdi for ; Wed, 18 Jan 2017 16:14:29 -0800 (PST) Received: from mail-ot0-x22a.google.com (mail-ot0-x22a.google.com [IPv6:2607:f8b0:4003:c0f::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAE3B1294C1 for ; Wed, 18 Jan 2017 16:14:28 -0800 (PST) Received: by mail-ot0-x22a.google.com with SMTP id 65so20854983otq.2 for ; Wed, 18 Jan 2017 16:14:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MnKk1MZSU+NswR4tkRw9udMPJUB97kU2FSdSwjxb8Xo=; b=Za7JjZkzaMUyUWwee7KU2u0DJ0RzHD30pMqwrN5111jKh/fO3xU5SC0sGTpNsL2dwi mO/Bbc4pSXkhybMaO5IsIxq1ieUjJcIQyTR3cumQt/mQBZ8NCD5tQevWnqJKzPV7FucG UBDdAjcAHvXwcJVmcXJLCRjJFVqaqXAo61GcmtQE25xAhVYWaXIVxjL8mNaAZmeXrEZs 00Yu86T3GfJ22HlnpgrzH///VwczJrrAYuXXshX8lVr9BRSbh9YVYfXhPsxZ2UKhokFR ulzCBymOVzvvav4Ks+zdLXXz0TFkTnoPVzJqEV5fqNQnL2ndybijyeWus6yicuBUw/Sh 9RSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MnKk1MZSU+NswR4tkRw9udMPJUB97kU2FSdSwjxb8Xo=; b=Tv03Yw+iEmPuR6d4gZ3VoSe91Pr/EMR4SZbgFsfuJIo9d6m7CeXiw2ABbw/XBPq7su 9zPdgvwYTkff/1BjekEPrbDIIhv66iJ4j+ZlKOQoyFtQzNGs8Aa+cfTqwG6K9sacpAIR NUnuHcnpdT8c2JOLEEAX+3CCKctPheBz7O5shmuIf39OOm8m13JDgTQmRN2zZoJoZiDw VeVbfvvPcGZyz23dZnDywfGX/GOwrOsQ8uYAxB0mmQTQX2BB/lJg+zepiObtzfKRpcff HojGHkYMMqyoZDbaYcJFx+KMp0NBBsZn++fKfnGnBs+nVdS500qpX1kmkosSr/bCK3kw L/hg== X-Gm-Message-State: AIkVDXIgc/zjDdIinwsoiZPJMME9ptiAFYci2BIbr4t3+960inpsySD68lMrf7Bq4IjZZfRRg7C2GvCSZBNzbQ== X-Received: by 10.157.37.209 with SMTP id q75mr3209940ota.267.1484784868252; Wed, 18 Jan 2017 16:14:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.227.102 with HTTP; Wed, 18 Jan 2017 16:14:27 -0800 (PST) In-Reply-To: References: <6b761ce0-acb6-8e16-45c5-07fa9fa2f620@isi.edu> From: Hemant Singh Date: Wed, 18 Jan 2017 19:14:27 -0500 Message-ID: To: Joe Touch Content-Type: multipart/alternative; boundary=001a113db4b2a3e1850546676a43 Archived-At: Cc: v6ops list Subject: Re: [v6ops] TCP related attacks/RFC3128 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 00:14:31 -0000 --001a113db4b2a3e1850546676a43 Content-Type: text/plain; charset=UTF-8 Hi Joe, On Tue, Jan 17, 2017 at 11:56 AM, Joe Touch wrote: If you're talking about fragments, then you need to describe the case more > clearly. IMO, a firewall always needs to reassemble fragments. > > Yes, it's an attack using fragments. An ACL is configured on the router to allows telnet and ssh only from certain source IP addresses. An attacker uses a source IP port that does not match any source in the ACL. However, the router has a incorrect implementation for ACLs (or ACL rules is mis-configured) which processes fragmented packets first before matching source IP. Once the first fragment is allowed, the subsequent fragments are let through. The source IP is checked later in the implementation and thus the hacker gets into the network. An authentication server serving the router is the last defense against such a hack because a login and password is required. > > Remember that an IPv4 packet with DF=0 can be fragmented anywhere in the > network and both IPv4 and IPv6 can be fragmented at the source. > > IPv4 requires that a 68 byte packet can traverse the net without > fragmentation but there are no rules that prohibit smaller packets or > fragments. E.g., if you are sending a 100-byte packet and it needs to be > fragmented down to 68 bytes, it's entirely valid to make the first fragment > as 32 bytes. Anything longer than the IP header ought is defined as valid. > > When I get the time, I will check the Linux code and see if it has anything hard coded for minimum IPv4 packet size. Thanks for your other replies - make total sense. I am all set. Best Regards, Hemant > > --001a113db4b2a3e1850546676a43 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Joe,


On Tue, Jan 17, 2017 at 11:56 AM, Joe Touch <touch@isi.edu> wrote:

If you're talking about fragments, then=C2=A0 you need to describe = the case more clearly. IMO, a firewall always needs to reassemble fragments.

<hs> Yes, it's an attack u= sing fragments.=C2=A0 An ACL is configured on the router to allows telnet a= nd ssh only from certain source IP addresses.=C2=A0 An attacker uses a sour= ce IP port that does not match any source in the ACL.=C2=A0 However, the ro= uter has a incorrect implementation for ACLs (or ACL rules is mis-configure= d) which processes fragmented packets first before matching source IP. =C2= =A0 Once the first fragment is allowed, the subsequent fragments are let th= rough.=C2=A0 The source IP is checked later in the implementation and thus = the hacker gets into the network.=C2=A0 An authentication server serving th= e router is the last defense against such a hack because a login and passwo= rd is required.=C2=A0

 Remember that an IPv4 packet with DF=3D0 can be fragmented anywhere in the network and both IPv4 and IPv6 can be fragmented at the source.

IPv4 requires that a 68 byte packet can traverse the net without fragmentation but there are no rules that prohibit smaller packets or fragments. E.g., if you are sending a 100-byte packet and it needs to be fragmented down to 68 bytes, it's entirely valid to mak= e the first fragment as 32 bytes. Anything longer than the IP header ought is defined as valid.

<hs> When I get the time, I wi= ll check the Linux code and see if it has anything hard coded for minimum I= Pv4 packet size.=C2=A0 Thanks for your other replies - make total sense.=C2= =A0 I am all set.

Best Regards,

Hemant=C2=A0
=


--001a113db4b2a3e1850546676a43-- From nobody Wed Jan 18 16:45:23 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C7B2129445 for ; Wed, 18 Jan 2017 16:45:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.098 X-Spam-Level: X-Spam-Status: No, score=-10.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=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 shl0yWFRaMtQ for ; Wed, 18 Jan 2017 16:45:20 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C555127078 for ; Wed, 18 Jan 2017 16:45:20 -0800 (PST) Received: from [128.9.184.94] ([128.9.184.94]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v0J0ifZJ013002 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 18 Jan 2017 16:44:42 -0800 (PST) To: Hemant Singh References: <6b761ce0-acb6-8e16-45c5-07fa9fa2f620@isi.edu> From: Joe Touch Message-ID: <713bae8b-2b00-e94f-9d2c-a609dd154dde@isi.edu> Date: Wed, 18 Jan 2017 16:44:41 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------0CE9ECABC94D6717D872C399" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: v6ops list Subject: Re: [v6ops] TCP related attacks/RFC3128 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 00:45:21 -0000 This is a multi-part message in MIME format. --------------0CE9ECABC94D6717D872C399 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi, Hemant, It's useful to note that the attack isn't based solely on minimum packet size; it depends on how duplicate and overlapping fragment are handled as well. The best approach for a firewall is to reassemble such packets. If it implements an ACL, it's acting like an end host in peeking into the payload; there's no meaningful or safe way to do so when fragmentation occurs other than reassembly, IMO. Joe On 1/18/2017 4:14 PM, Hemant Singh wrote: > Hi Joe, > > > On Tue, Jan 17, 2017 at 11:56 AM, Joe Touch > wrote: > > If you're talking about fragments, then you need to describe the > case more clearly. IMO, a firewall always needs to reassemble > fragments. > > Yes, it's an attack using fragments. An ACL is configured on the > router to allows telnet and ssh only from certain source IP > addresses. An attacker uses a source IP port that does not match any > source in the ACL. However, the router has a incorrect implementation > for ACLs (or ACL rules is mis-configured) which processes fragmented > packets first before matching source IP. Once the first fragment is > allowed, the subsequent fragments are let through. The source IP is > checked later in the implementation and thus the hacker gets into the > network. An authentication server serving the router is the last > defense against such a hack because a login and password is required. > > > Remember that an IPv4 packet with DF=0 can be fragmented anywhere > in the network and both IPv4 and IPv6 can be fragmented at the > source. > > IPv4 requires that a 68 byte packet can traverse the net without > fragmentation but there are no rules that prohibit smaller packets > or fragments. E.g., if you are sending a 100-byte packet and it > needs to be fragmented down to 68 bytes, it's entirely valid to > make the first fragment as 32 bytes. Anything longer than the IP > header ought is defined as valid. > > When I get the time, I will check the Linux code and see if it > has anything hard coded for minimum IPv4 packet size. Thanks for your > other replies - make total sense. I am all set. > > Best Regards, > > Hemant > > > --------------0CE9ECABC94D6717D872C399 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi, Hemant,

It's useful to note that the attack isn't based solely on minimum packet size; it depends on how duplicate and overlapping fragment are handled as well.

The best approach for a firewall is to reassemble such packets. If it implements an ACL, it's acting like an end host in peeking into the payload; there's no meaningful or safe way to do so when fragmentation occurs other than reassembly, IMO.

Joe


On 1/18/2017 4:14 PM, Hemant Singh wrote:
Hi Joe,


On Tue, Jan 17, 2017 at 11:56 AM, Joe Touch <touch@isi.edu> wrote:

If you're talking about fragments, then  you need to describe the case more clearly. IMO, a firewall always needs to reassemble fragments.

<hs> Yes, it's an attack using fragments.  An ACL is configured on the router to allows telnet and ssh only from certain source IP addresses.  An attacker uses a source IP port that does not match any source in the ACL.  However, the router has a incorrect implementation for ACLs (or ACL rules is mis-configured) which processes fragmented packets first before matching source IP.   Once the first fragment is allowed, the subsequent fragments are let through.  The source IP is checked later in the implementation and thus the hacker gets into the network.  An authentication server serving the router is the last defense against such a hack because a login and password is required. 

 Remember that an IPv4 packet with DF=0 can be fragmented anywhere in the network and both IPv4 and IPv6 can be fragmented at the source.

IPv4 requires that a 68 byte packet can traverse the net without fragmentation but there are no rules that prohibit smaller packets or fragments. E.g., if you are sending a 100-byte packet and it needs to be fragmented down to 68 bytes, it's entirely valid to make the first fragment as 32 bytes. Anything longer than the IP header ought is defined as valid.

<hs> When I get the time, I will check the Linux code and see if it has anything hard coded for minimum IPv4 packet size.  Thanks for your other replies - make total sense.  I am all set.

Best Regards,

Hemant 



--------------0CE9ECABC94D6717D872C399-- From nobody Wed Jan 18 16:51:18 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 564DE1294A1 for ; Wed, 18 Jan 2017 16:51:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 AWMCg8ZOVm4b for ; Wed, 18 Jan 2017 16:51:16 -0800 (PST) Received: from mail-pg0-x244.google.com (mail-pg0-x244.google.com [IPv6:2607:f8b0:400e:c05::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D660127078 for ; Wed, 18 Jan 2017 16:51:16 -0800 (PST) Received: by mail-pg0-x244.google.com with SMTP id 204so2608754pge.2 for ; Wed, 18 Jan 2017 16:51:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=SLblOOmtfie88fyx1JrDW6IQAoZgwbomCYpuuNXK1MU=; b=K2I5JcjoQRYaV7nNZwnEhDRO/Z9kC3eXNH0BuZJCO/j6xQp8nr6ZkXQJezB8PyZxW9 nq7hWZcaeevHMOtmTSTlQGLHaM3t3Rqdeoe7XENrIB2zB77SAXE98XxVPigXdrijtVtu +p4aFM6aq3GcrrghTbh1nSC8Ad41DAck5T+oJuu3StzFM790mi5cB3+ly+ZgeZ5dTYEe PYzN/l0vZ9IW5et1CkDS2w6J9beYHh1GGXIMYAPhgyep+rMVPG14Mdz01zGvEkx/7HYN iqbfWD0L3Eba1KrpshNbRQqVXRZ+zy2GWagHtqUVnnx+Lp9LNzBSTzpDicDjl/g0bgmk 9c6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=SLblOOmtfie88fyx1JrDW6IQAoZgwbomCYpuuNXK1MU=; b=McACtbc0WIwOLYhLzje1D05D5vqmZHvvoerdcsWm2nCDSmiOsZ/8fssTufOb1gL2BL XfWp+qVNodImyBNGnnztd33QT6HJXNJuDjPoTxQBs4KhyLR7uKcHlYr3ZwAQIgDM19L2 1M6dzajCy08x0Uy56aGCtodqzs5zQYS7x1dcEDaWe7YpFIeLX3R83Uus0u/r/6KrDrWI wVYNuLJN/0XN5VC5dhBjUQBDzsMxQyO9rf/0I2JOZZxZBnrM4spcSIQKdNqc56bw6IEo BcKETvk44QHlJId0yPqlpQRrsc09NK3fu94QQF+c8XWfpCfs5gdZdt+0jsvdVE+vsrWN FnpQ== X-Gm-Message-State: AIkVDXJi+5NttqbgklDkVCEtWlCK33aKs2pG6Vf06OyY6WgO3kpSMu2FJFYXmZo3Dio0Fw== X-Received: by 10.98.210.3 with SMTP id c3mr6874854pfg.7.1484787075642; Wed, 18 Jan 2017 16:51:15 -0800 (PST) Received: from [192.168.178.21] ([118.148.124.183]) by smtp.gmail.com with ESMTPSA id e90sm3437591pfl.32.2017.01.18.16.51.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Jan 2017 16:51:15 -0800 (PST) To: =?UTF-8?B?56We5piO6YGU5ZOJ?= , "Liubing (Leo)" References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2E981DF@nkgeml514-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2E986B1@nkgeml514-mbx.china.huawei.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <6a35dea9-9484-4fe9-6b4d-50eba64a1858@gmail.com> Date: Thu, 19 Jan 2017 13:51:14 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: IPv6 Ops WG , "v6ops-chairs@tools.ietf.org" Subject: Re: [v6ops] Possible consensus of dhcpv6-slaac-problem draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 00:51:17 -0000 On 19/01/2017 07:30, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: =2E.. >=20 > BTW, I guess trying to be "comprehensive" is actually one major reason > why I cannot be so enthusiastic about the current content of the > draft. IMO this exact attempt makes the draft look "random". Could this be fixed by separating the issues into "major" and "minor"? Brian From nobody Wed Jan 18 17:01:32 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17140129516 for ; Wed, 18 Jan 2017 17:01:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 BGVlE5DR8vxV for ; Wed, 18 Jan 2017 17:01:29 -0800 (PST) Received: from mail-pg0-x242.google.com (mail-pg0-x242.google.com [IPv6:2607:f8b0:400e:c05::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C06FE129442 for ; Wed, 18 Jan 2017 17:01:29 -0800 (PST) Received: by mail-pg0-x242.google.com with SMTP id 204so2628388pge.2 for ; Wed, 18 Jan 2017 17:01:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=ZsPKVtCPeQ6eJU8AoDYWExXR+OQCjuba87Ait0XeFpg=; b=VwHkHue5EWASVNSlme12zgJA9W1gpVhP1ugaUR3f5hirWfrc/SLrfOMCNlug55HE05 gZukv/MywpheQzt3UmU4Tr9dFZiLjn2BPL05vCZa2rOIWCT3ooDGZENW8Hn5Mmo7rQ00 59KQbfWSvcwOtr7tI5Ml0oQ5x5LH116rI68HGlu5nu9brXlA8B0tFw7rKxf7Gcp/w3RJ Ng+W3xtZDIhJNfjmP/e5Po5Uyn9jm8m+g10yqWiWzqfxPu+LmBbuGKIBHlqNaeGlAjKJ QKIVf8S2DmWaiKt9mNcKmVi+nne4Ez+nuncgW5xQS2vnP6Pb/zRFt7fDpV/6IZOGHKhS SfKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=ZsPKVtCPeQ6eJU8AoDYWExXR+OQCjuba87Ait0XeFpg=; b=Vho46iUN0qbC2D7/Qe8Hw9RifTWzpnZtRSBnkqMqQHi4sgiqurSZU4Y4+5299GcNdE JazcpPhQRU5HOeJl8cnPdYHVh61UwVePTK42SQKiXlrCnj3sopISSbdPYS9+jemhq5PH WEEacRiH0sOfH34fAFLPQjqKbkRYE+f1Jyk3fAFoZxggbk78k73QjDxQPocecQUoMKWo 1yDH29Fgoq7qkvNxYFmHDcU+5ZeYVZ2lMJJ2pUVqm2nfnUksT2RbyvnqpyM4904RvGiY mlsiusKl26PF/sI2/tqchCe8ND8pyH374Jc4DM1v9jYryPUlGJse8Dqj68i1qy13uoip 1rfQ== X-Gm-Message-State: AIkVDXLEP8gdheMCqMh+UuuiTBrjfc5CG1G9ORVl+wilRn9Kkbnv9673MbcMW4nYSKpCZA== X-Received: by 10.98.223.66 with SMTP id u63mr6932786pfg.39.1484787689062; Wed, 18 Jan 2017 17:01:29 -0800 (PST) Received: from [192.168.178.21] ([118.148.124.183]) by smtp.gmail.com with ESMTPSA id a24sm3462192pfh.33.2017.01.18.17.01.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Jan 2017 17:01:28 -0800 (PST) To: Mark Smith References: <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <20170117.170305.74705723.sthaug@nethelp.no> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 19 Jan 2017 14:01:27 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Fernando Gont , v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 01:01:31 -0000 On 18/01/2017 12:29, Mark Smith wrote: > On 18 January 2017 at 09:57, Brian E Carpenter > wrote: >> On 18/01/2017 05:52, Mark Smith wrote: >> ... >>> DHCPv6 is more capable, flexible and general purpose. >> >> Indeed. When campus network operators and ISPs tell us unambiguously, >> as they do, that they require feature equivalence between DHCP for IPv4 >> and DHCP for IPv6, we would be incredibly arrogant to ignore them. >> >>> (I'm not making the assertion that if you use DHCPv6 then you must use >>> it for addresses. That's a choice available, however I would use SLAAC >>> for addresses and stateless DHCPv6 for the other upper layer host >>> parameters.) >> >> Many campuses want to use DHCPv6 for address assignment, however. > > So I am always interested to know what problem they're trying to solve > then they say that. I expect it is address use/auditability for > security purposes. So I understand. If they are using an IPAM* tool that was developed around DHCP, *not* using DHCPv6 for address management becomes a problem in itself, *IPAM = IP Address Management > I then wonder if they've put in place companion > measures to prevent hosts from using addresses configured statically, Typically they will pre-register MAC addresses and police accordingly, because that keeps unauthorised devices off the network, which is the main goal. But this *can* be combined with SLAAC (the University of Auckland is a running example, and I'm sure there are many others), and there are IPAM tools that play nice with SLAAC. The challenge is sites that *want* to use DHCPv6 (and are not going to take any notice if the IETF sulks). > or measures to prevent an entirely new prefix being brought up on the > link by hosts via static configuration, that won't be recorded in the > DHCPv6 address database. Well, that would be a problem with SLAAC too, wouldn't it? I'd expect any such prefix to be blocked by the first router it came to. Brian >> (That doesn't mean banning SLAAC, though apparently some do that too.) >> >> On 18/01/2017 06:33, Mark Smith wrote: >> ... >>> This "IPv4+NAT only" generation will only last for a short period in >>> the life of IPv6. We should be careful not to hobble IPv6 to suit >>> their relatively limited world view. >> >> Agreed, but feature-equivalence for DHCPv6 doesn't do that. The great >> thing about SLAAC is that it works very well *without* DHCPv6 in >> simple deployments. But unless we extend RAs to supply every parameter >> that DHCP can supply, > > Agree, that's what we want to avoid. > >> DHCPv6 *will* be used in most large networks. >> > > What I'm not understanding is a seemingly common belief that DNS is > the only parameter that needs to be configured on general purpose > hosts, therefore only RDNSS is necessary, and therefore all hosts > should support RDNSS. > > This is even though RDNSSs functionality is so limited compared to > stateless DHCPv6, that the moment you need to deploy automated > configuration of anything else, you're going to have to deploy (at > least stateless) DHCPv6. If you deploy stateless DHCPv6 in the first > place for DNS, you avoid issues and limitations that RDNSS has, and > you can easily add providing other DHCPv6 supported parameters such as > NTP at a later time. > > > Regards, > Mark. > From nobody Wed Jan 18 17:06:48 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2DAD1295A5 for ; Wed, 18 Jan 2017 17:06:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 cf4hssvTMPjJ for ; Wed, 18 Jan 2017 17:06:44 -0800 (PST) Received: from mail-pg0-x244.google.com (mail-pg0-x244.google.com [IPv6:2607:f8b0:400e:c05::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4633F129527 for ; Wed, 18 Jan 2017 17:06:44 -0800 (PST) Received: by mail-pg0-x244.google.com with SMTP id 204so2639052pge.2 for ; Wed, 18 Jan 2017 17:06:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=Ay6hAw3jDoRiKHiiihMaRmPoq+WrS+aE6oDSdsjDvVo=; b=rITsSXFzPHFJ57sKpWJB8umAC97aldgl2yVu9Ibu29QFChXBw9LqQQPkadSLCEPnph W33kd7YDE17P6b2y7KNCxkQM9lu58HVBztWReQ0wg8D2p5kikuQ4FatwR9e9Rkqz0kk6 DEkKNmPyohnpqYjVufSscU/DNNMBWPemqUh++K2MsNV2nY/PUGP9Gv4SeGzSQRa7Rhpd VRzdPyz1terYItLNTB3O9wvhkjES4eN3v4lPfyPVWpn9HapUc+eTVc58xr7uMmFi4Mpu dDd9+zQtpHGT87ndciWe9CGTvOyedcb+i0LtXjg3ChU1KB6rETZLRQkbCCFqF3zXm5fG aABw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=Ay6hAw3jDoRiKHiiihMaRmPoq+WrS+aE6oDSdsjDvVo=; b=ecGV8niT9EsgyQ9LfcrT5R+otGiobfIHBx4Ny0tmgiYMAEojPq47BmJ6Jt8dlir7sW JNqkEWjFVwIqzjr3Q1JrguM7qjm1kDxcRuuT7V4xK9PT3lhioR9+3G1mMi8srAbjargZ asTpxuqsurNegX177YxeYoncagbzA/4pHnP0x+GLx5KgKdQcGsVaJvzPm0w4449kIhnH mnuGX9GdCguUtuenU184aQKNq2z/8LC880+NSmZZaKab93GhXmmKkMSn5zWFQhuPvlGS hf0Eiw8GwdS25jJMJcuYSYKC4bMIvKCZYq45/mtQ5rHs9RiY6qGwTMTy4IRzF0avqO19 vWCw== X-Gm-Message-State: AIkVDXK73nmdOXS0nVchjR+DXKmXvtlxMGnxrCphh7g7ShFaw63OrsLsAPxoB8+Edi2Ucg== X-Received: by 10.84.142.70 with SMTP id 64mr9229109plw.177.1484788003720; Wed, 18 Jan 2017 17:06:43 -0800 (PST) Received: from [192.168.178.21] ([118.148.124.183]) by smtp.gmail.com with ESMTPSA id r26sm3400175pgd.42.2017.01.18.17.06.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Jan 2017 17:06:43 -0800 (PST) To: Lorenzo Colitti , Mark Smith References: <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <20170117.170305.74705723.sthaug@nethelp.no> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 19 Jan 2017 14:06:42 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Fernando Gont , v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 01:06:45 -0000 On 18/01/2017 20:16, Lorenzo Colitti wrote: ... > All these make DHCPv6 a rather bad idea for networks that change without > advance warning, such as home networks I hope nobody is disputing that. But when enterprise network operators tell us the DHCPv6 is a rather good idea for their planned and managed networks, we need to listen, I think. Brian From nobody Wed Jan 18 17:21:27 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05E0C1293E9 for ; Wed, 18 Jan 2017 17:21:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 2YS9yQuWb4Rx for ; Wed, 18 Jan 2017 17:21:25 -0800 (PST) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8208129527 for ; Wed, 18 Jan 2017 17:13:27 -0800 (PST) Received: by mail-pf0-x22a.google.com with SMTP id f144so8513939pfa.2 for ; Wed, 18 Jan 2017 17:13:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=TijnLvCmhzHbmiYiFpPElLvZfrFHvAwvYSVjiB5lIig=; b=VjNWxdlM7NjD0OgRapPhZndfbJwO12ZgFh6YVrWjtBxpsbBbm/MSfFo7iKpDaK0y79 PspnSDMywEBVO1yZrmuiiYg3Hmgn7v+dvQ71VFy41xo/yl9zm1VpZMbivy/rNLldCAIR uCx6XOyon8qcO8clmoAyLDzPVxVYOQUqBFjZDxANzEitux2oxcTsYwqMxy8gb7TyeTWP +nBW5HKR0fZ85PDRCV2wLiavMhfbWp3ztgGADh9U+XJgo+VEiZy7e/rviWLAcKcpJVty 6uHo52VtlkeIioA5bNyD9Nt27maRRibS8flZrDkqykYWg0zPkOCtosI5jt8O8b54ioUX 1oWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=TijnLvCmhzHbmiYiFpPElLvZfrFHvAwvYSVjiB5lIig=; b=psigRSBwBn8a0ybZv3lK7UL8vf4fkXvlPNk/4V0uwO/10QMIzyXGQ453CkZWSilJBX 3f7760mLNnoIXWR7RskE6Zg0vG+uMSWFHDZ9d2yUAckeEPSmLUZKdY2+afNUIvEKErej /y1vPqoIn3foDL/CTAMEeWMck6ZNtHQsDn3SmRC2LM30j/3fxoDM3XiP2WgHRA51tHWS Y+Oip2gbGgJQzxuwaAEIl9mDnV3nVn9Pr7pAP0SttcyoqVT9jbwW5IW0FF5/rF3XNMPH qCkmydBmkXVhYmHdx9f+sbP9I4G7CKkZp+bFIPUvJ6MgdOZNflE2vX0D+33tkqzGOexE uz4Q== X-Gm-Message-State: AIkVDXJJKJPaJd16TNwv8lt0wJmwq16zfZHqYqarM4KRi7eP0USKyEDelGGHdS09x/svCw== X-Received: by 10.99.101.65 with SMTP id z62mr7376540pgb.74.1484788407221; Wed, 18 Jan 2017 17:13:27 -0800 (PST) Received: from [192.168.178.21] ([118.148.124.183]) by smtp.gmail.com with ESMTPSA id g28sm3586014pgn.3.2017.01.18.17.13.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Jan 2017 17:13:26 -0800 (PST) To: Mark Smith , "STARK, BARBARA H" References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <6f3241eb-9d47-0a6e-7c0d-e9b5a69b86d0@si6networks.com> <2D09D61DDFA73D4C884805CC7865E6114DA941D1@GAALPA1MSGUSRBF.ITServices.sbc.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <962bf6cb-9fc7-c8aa-0418-7a38d2d2d26c@gmail.com> Date: Thu, 19 Jan 2017 14:13:25 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Fernando Gont , IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 01:21:26 -0000 On 19/01/2017 08:17, Mark Smith wrote: ... > The question is that if a host is so resource constrained that it > can't run a stateless DHCPv6 client, is it actually capable of running > a compliant IPv6 stack? I wouldn't think so, so I don't think the > justification for RDNSS is really valid. I don't think that computes. Every kB less matters and every code path that doesn't consume battery matters. Also, I get the impression that mDNS is very popular in such nodes, so maybe they don't need RDNSS at all. The justification for RDNSS was one level up from IoT: simple home networks, cafe networks, etc. only need SLAAC and RA, but they do need a DNS server. Brian From nobody Wed Jan 18 18:50:38 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74B35129464 for ; Wed, 18 Jan 2017 18:50:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.42 X-Spam-Level: X-Spam-Status: No, score=-7.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 wCoprSn2JJyM for ; Wed, 18 Jan 2017 18:50:34 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16ECA129453 for ; Wed, 18 Jan 2017 18:50:32 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CZC25052; Thu, 19 Jan 2017 02:50:30 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 19 Jan 2017 02:50:29 +0000 Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Thu, 19 Jan 2017 10:50:22 +0800 From: "Liubing (Leo)" To: =?utf-8?B?56We5piO6YGU5ZOJ?= Thread-Topic: [v6ops] Possible consensus of dhcpv6-slaac-problem draft Thread-Index: AQHScG+u/Kql0lmeGEKlzbtVJBMOt6E8tVCAgADJwJCAAIv1AIABCy2Q Date: Thu, 19 Jan 2017 02:50:21 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45C2E98BCF@nkgeml514-mbx.china.huawei.com> References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2E981DF@nkgeml514-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2E986B1@nkgeml514-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.191.175] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.58802976.00AA, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 53f4ebddcc65588dc06dd05692f6e718 Archived-At: Cc: IPv6 Ops WG , "v6ops-chairs@tools.ietf.org" Subject: Re: [v6ops] Possible consensus of dhcpv6-slaac-problem draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 02:50:36 -0000 SGkgSmlubWVpLA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGppbm1l aS50YXR1eWFAZ21haWwuY29tIFttYWlsdG86amlubWVpLnRhdHV5YUBnbWFpbC5jb21dIE9uDQo+ IEJlaGFsZiBPZiDnpZ7mmI7pgZTlk4kNCj4gU2VudDogVGh1cnNkYXksIEphbnVhcnkgMTksIDIw MTcgMjozMSBBTQ0KPiBUbzogTGl1YmluZyAoTGVvKQ0KPiBDYzogSVB2NiBPcHMgV0c7IHY2b3Bz LWNoYWlyc0B0b29scy5pZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBQb3NzaWJsZSBj b25zZW5zdXMgb2YgZGhjcHY2LXNsYWFjLXByb2JsZW0gZHJhZnQNCj4gDQo+IEF0IFdlZCwgMTgg SmFuIDIwMTcgMDI6NDU6MzggKzAwMDAsDQo+ICJMaXViaW5nIChMZW8pIiA8bGVvLmxpdWJpbmdA aHVhd2VpLmNvbT4gd3JvdGU6DQo+IA0KPiA+IFBlcnNvbmFsbHksIG9uZSBvZiB0aGUgbWFpbiBp c3N1ZXMgb2YgZGhjcHY2LXNsYWFjLXByb2JsZW0gaXMgbm90DQo+ID4gYWJvdXQgYmVoYXZpb3It b25seSB2cyBwcm9ibGVtIGRlc2NyaXB0aW9uLCBidXQgdGhhdCBpdCB0YWxrcyBhYm91dA0KPiA+ IChzZWVtaW5nbHkpIHJhbmRvbSB0b3BpY3MgbW9zdCBvZiB3aGljaCBkb24ndCBzZWVtICh0byBt ZSkgdG8gaGF2ZQ0KPiBwcmFjdGljYWwgaW1wb3J0YW5jZS4NCj4gPiBbQmluZ10gSSBkb24ndCBx dWl0ZSB1bmRlcnN0YW5kIHdoYXQgeW91IHNhaWQgInJhbmRvbSB0b3BpY3MiIG1lYW4uIFRoaXMN Cj4gZG9jdW1lbnQgaXMgYWN0dWFsbHkgZm9jdXNpbmcgb24gYSB2ZXJ5IHNwZWNpZmljIHRvcGlj IC0gdGhlIGFtYmlndWl0eSBvZiB0aGUNCj4gTS9PIGZsYWdzLCBhbmQgdGhlIGRpdmVyZ2VudCBi ZWhhdmlvcnMgY2F1c2VkIGJ5IHRoZSBhbWJpZ3VpdHkuDQo+IA0KPiA+IFdlIGhhZCBhIChhcyBt dWNoIGFzIHdlIGNvdWxkIGRpZCkgY29tcHJlaGVuc2l2ZSBhbmFseXNpcyBvZiB0aGUNCj4gPiBh bWJpZ3VpdHkgcG9zc2liaWxpdGllcyBmcm9tIHRoZSBlYXJseSB2ZXJzaW9ucyBkcmFmdHMuIEFu ZCB3ZQ0KPiA+IG9ic2VydmVkIGRpdmVyZ2VuY2Ugb24gZWFjaCBvZiB0aGUgcG9zc2liaWxpdGll cy4gU28sIHBlcnNvbmFsbHkgSQ0KPiA+IGRvbid0IHRoaW5rIHRoZSBkcmFmdCBpcyBkaXNjdXNz aW5nIHNvbWV0aGluZyByYW5kb21seS4NCj4gDQo+IEkgbWVhbnkgYnkgInJhbmRvbWx5IiB0aGF0 IGl0IGNvbnNpc3RzIG9mIGltcG9ydGFudCBhbmQgbm9uLWltcG9ydGFudA0KPiBkaXZlcmdlbnQg YmVoYXZpb3JzLiAgSSB0aG91Z2h0IEkgc3BlY2lmaWNhbGx5IGV4cGxhaW5lZCB0aGVzZSBpbiBt eSBsYXRlc3QNCj4gcmV2aWV3IGNvbW1lbnRzIGZvciB0aGUgZHJhZnQuDQo+IA0KPiBCVFcsIEkg Z3Vlc3MgdHJ5aW5nIHRvIGJlICJjb21wcmVoZW5zaXZlIiBpcyBhY3R1YWxseSBvbmUgbWFqb3Ig cmVhc29uIHdoeSBJDQo+IGNhbm5vdCBiZSBzbyBlbnRodXNpYXN0aWMgYWJvdXQgdGhlIGN1cnJl bnQgY29udGVudCBvZiB0aGUgZHJhZnQuICBJTU8gdGhpcw0KPiBleGFjdCBhdHRlbXB0IG1ha2Vz IHRoZSBkcmFmdCBsb29rICJyYW5kb20iLg0KDQpbQmluZ10gT2ssIEkgZ2V0IHlvdXIgcG9pbnQu DQoNCj4gPiBPZiBjb3Vyc2UsIHdoYXQgaXMgaW1wb3J0YW50IGFuZCB3aGF0IGlzIG5vdCBpcyBx dWl0ZSBzdWJqZWN0aXZlLCBzbyBpdCdzIG5vdA0KPiBzdXJwcmlzaW5nIGlmIHNvbWUgb3RoZXIg cGVvcGxlIGNvbnNpZGVyIG1vc3QvYWxsIG9mIHRoZSB0b3BpY3MgYXJlDQo+IGltcG9ydGFudC4N Cj4gPiBCdXQgbXkgaW1wcmVzc2lvbiBmcm9tIHRoZSBwYXN0IGFuZCBjdXJyZW50IGRpc2N1c3Np b24gb2YgdGhlIGRyYWZ0IGlzIHRoYXQNCj4gaXQncyBhdCBsZWFzdCBub3Qgb25seSBtZS4NCj4g DQo+ID4gW0JpbmddIFRoZXJlIHdlcmUgc2V2ZXJhbCBwZW9wbGUgZG9uJ3QgYWdyZWUgdGhlICJw cm9ibGVtcyIgZGlzY3Vzc2VkIGluDQo+IHRoaXMgZG9jdW1lbnQgd2VyZSAicmVhbGx5IHByb2Js ZW1zIi4gSSB1bmRlcnN0YW5kIGl0IGlzIG5vdCBlYXN5IHRvIGdldA0KPiBjb25zZW5zdXMuDQo+ ID4gQnV0IEkgYWxzbyBoYXZlIGFuIGltcHJlc3Npb24gdGhhdCBwZW9wbGUgaW4gZ2VuZXJhbCB0 aGluayBpdCdzIGdvb2QgdG8NCj4gcmVjb3JkIGFuZCBwdWJsaXNoIHRoZSBhbWJpZ3VpdHkgYW5k IHRoZSBkaXZlcmdlbnQgYmVoYXZpb3JzLg0KPiANCj4gSSBkb24ndCBkZW55IHNvbWUgb3RoZXIg cGVvcGxlIG1pZ2h0IHRoaW5rIGV2ZW4ganVzdCBkZXNjcmliaW5nICJyYW5kb20iDQo+IGJlaGF2 aW9ycyBpcyBhIGdvb2QgdGhpbmcuICBJIGp1c3QgcGVyc29uYWxseSBkaXNhZ3JlZSB3aXRoIHRo YXQgcG9zaXRpb24sDQo+IHNpbmNlIGl0IHdpbGwgcmVzdWx0IGluIGEgbXVjaCBsZXNzIHVzZWZ1 bCBkb2N1bWVudCBhZnRlciBzcGVuZGluZyBhIGxvdCBvZiB3Zw0KPiBlbmVyZ3kuICBJTU8gaXQn cyB3b3JzZSB0aGFuIG5vdCBwdWJsaXNoaW5nIGl0IGF0IGFsbC4NCj4gDQo+ID4gSW4gdGhpcyBz ZW5zZSwganVzdCBmb2N1c2luZyBvbiBkZXNjcmliaW5nIHRoZSByYW5kb20gYmVoYXZpb3JzIGRv ZXMgbm90DQo+IHNvdW5kIG9rYXkgdG8gbWUuDQo+ID4gV2hhdCBJIHdhbnQgdG8gc2VlIGlzIHRv IGhhdmUgc29tZSBsZXZlbCBvZiBjb25zZW5zdXMgb24gd2hhdCBpcw0KPiBpbXBvcnRhbnQgYW5k IHByYWN0aWNhbCBhbmQgZm9jdXMgb24gdGhlbS4NCj4gPiBbQmluZ10gQXMgeW91IHNhaWQsIHdo YXQgaXMgaW1wb3J0YW50IGFuZCB3aGF0IGlzIG5vdCBpcyBxdWl0ZSBzdWJqZWN0aXZlLiBTbw0K PiB3aHkgbm90IHdlIGp1c3Qga2VlcCB0aGUgb2JqZWN0aXZlIGZhY3QgYW5kIGxldCB0aGUgcmVh ZGVycy9hZG1pbmlzdHJhdG9ycw0KPiBkZWNpZGUgYWNjb3JkaW5nIHRvIHRoZWlyIHNwZWNpZmlj IHNpdHVhdGlvbi4NCj4gDQo+IEFnYWluLCBJIHBlcnNvbmFsbHkgZG9uJ3QgdGhpbmsgaXQgYSBn b29kIGlkZWEuICBCdXQgSSdtIGp1c3Qgb25lIG9yZGluYXJ5IHdnDQo+IHBhcnRpY2lwYW50IHdp dGhvdXQgYW55IHZpdG8gcG93ZXIgb3IgYW55dGhpbmcuICBZb3UgZG9uJ3QgbmVjZXNzYXJpbHkg aGF2ZQ0KPiB0byBjb252aW5jZSBtZSBpZiB5b3UgY2FuIHJlYWNoIGEgd2cgcm91Z2ggY29uc2Vu c3VzIHdpdGhvdXQgbXkgc3VwcG9ydC4NCg0KW0JpbmddIFNpbmNlIHlvdSBoYWQgYW4gZXhwbGlj aXQgcG9zaXRpb24sIHlvdXIgb3BpbmlvbiBtYXkgbW9yZSBvciBsZXNzIGltcGFjdCB0aGUgZHJh ZnQuIFNvLCBpZiB3ZSBjYW4gZ2V0IGNvbnNlbnN1cywgSSB0aGluayB3ZSBtb3JlIG9yIGxlc3Mg c3RlcCB0b3dhcmRzIFdHIHJvdWdoIGNvbnNlbnN1cy4NCklmIHdlIGNhbid0LCBhdCBsZWFzdCB3 ZSBuZWVkIHRvIGVsaW1pbmF0ZSBtaXN1bmRlcnN0YW5kaW5ncy4gRS5nLiBJIG1pc3VuZGVyc3Rv b2QgeW91ciBhcmd1bWVudCBhYm91dCAicmFuZG9tIi4NCg0KPiBJZiBJIHdlcmUgdGhlIGF1dGhv ciwgSSdkIHN0ZXAgYmFjayBhbmQgZm9jdXMgb24gb25lIG9idmlvdXNseSAiaW1wb3J0YW50Ig0K PiBwb2ludDogY29leGlzdGVuY2Ugb2YgU0xBQUMgYW5kIGFkZHJlc3MgYXNzaWdubWVudCBieQ0K PiBESENQdjYgaXNuJ3QgcG9zc2libGUgaW4gc29tZSBjYXNlcywgYW5kIHZlcnkgY2FyZWZ1bGx5 IGFkZCBvdGhlciBwb2ludHMgaWYNCj4gYW5kIHdoZW4gd2UgaGF2ZSBhIGdyZWF0ZXIgY29uc2Vu c3VzIHRoYXQgdGhleSBhcmUgb3BlcmF0aW9uYWxseQ0KPiBpbXBvcnRhbnQuICBCdXQgcGVyaGFw cyB5b3UnZCByYXRoZXIgYmUgImNvbXByZWhlbnNpdmUiDQo+IGFuZCBkb24ndCBsaWtlIHRoZSBp ZGVhIC0gaW4gdGhhdCBjYXNlLCBJIHRoaW5rIHdlIGp1c3QgaGF2ZSB0byBhZ3JlZSB0bw0KPiBk aXNhZ3JlZS4NCg0KW0JpbmddIFRoYW5rcyBmb3IgdGhpcyBjb25zdHJ1Y3RpdmUgc3VnZ2VzdGlv bi4gSSB0aGluayB0aGUgYW1iaWd1aXR5IGFuYWx5c2lzIG5lZWRzIHRvIGJlICJjb21wcmVoZW5z aXZlIjsgYnV0IG5vdCBuZWNlc3NhcmlseSB0aGUgb3BlcmF0aW9uYWwgZGl2ZXJnZW5jZS4NCkFz IEJyaWFuIHN1Z2dlc3RlZCBpbiBhbm90aGVyIHRocmVhZCwgZG8geW91IHRoaW5rIGl0IG1heSBo ZWxwIHRoZSBkcmFmdCBtb3JlIHJlYWRhYmxlIGlmIHdlIHNlcGFyYXRlIHRoZSBvcGVyYXRpb25h bCBkaXZlcmdlbmNlIGludG8gIk1ham9yIiBhbmQgIk1pbm9yIj8NCg0KQmVzdCByZWdhcmRzLA0K QmluZyANCg0KPiAtLQ0KPiBKSU5NRUksIFRhdHV5YQ0K From nobody Thu Jan 19 01:50:12 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88FCD129453 for ; Thu, 19 Jan 2017 01:50:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=steffann.nl 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 OLHQNLpf9RdF for ; Thu, 19 Jan 2017 01:50:09 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8FCC120727 for ; Thu, 19 Jan 2017 01:50:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 8B5FB4A; Thu, 19 Jan 2017 10:50:06 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:in-reply-to:date:date:subject:subject :mime-version:content-type:content-type:message-id:from:from :received:received; s=mail; t=1484819404; bh=7AK/QMTiyNnq93A6mIA 85Oewh+1YB8PD4s7I5aaOYfk=; b=YzpbDSC1xPnyTwfbUMmaqve08vwfH4e8jDR t4CaJogorf8+SQni7xNSGxzt1ScX//9U5Xfr9hiUPpG5s2UkM9OZDoKNNhAUGR5t aOs3u7f1GZqZt5Yas1z3jbJhSYL+lTnodqjQMU6NvUETfXWe+uA9DZ3TYN/VmOrg pTT63OR0= X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 9ZJO4tvyD1T4; Thu, 19 Jan 2017 10:50:04 +0100 (CET) Received: from [IPv6:2001:9e0:420:8001:89b7:549:9b4f:ac76] (unknown [IPv6:2001:9e0:420:8001:89b7:549:9b4f:ac76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.sintact.nl (Postfix) with ESMTPSA id CB4A549; Thu, 19 Jan 2017 10:50:04 +0100 (CET) X-Clacks-Overhead: GNU Terry Pratchett From: Sander Steffann Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_75CC85B4-7BB5-4851-AF95-F1CBB97879AA"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Date: Thu, 19 Jan 2017 10:50:04 +0100 In-Reply-To: To: Mark Smith References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <99204933-5CB6-4E89-BD6A-FD40136DF6F5@steffann.nl> X-Mailer: Apple Mail (2.3251) Archived-At: Cc: Fernando Gont , IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 09:50:10 -0000 --Apple-Mail=_75CC85B4-7BB5-4851-AF95-F1CBB97879AA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Mark, > So none this is religious, or if people participating are being > religious, then they shouldn't be participating. Engineering is > supposed to be about being objective, and debating and weighing up the > pros and cons of various options. Thanks, well said. > Implementing every option every > where to try to provide everybody with their favourite method > ("provide all options in both RA and DHCPv6") just creates complexity, > confusion, more code to write and more things that can break. That's a valid concern. I suggested using the same options for both RA = and DHCPv6 exactly for this reason: to keep things simpler. With the = current direction things seem to be moving to I'm afraid we're going to = end up with different options for DNS, NTP, default gateway etc in both = protocols, and that would be really bad. > I think when a discussion like this gets to this point, it is worth > revisiting the problem or problems being solved. >=20 > I think there are two problems to be/being solved: >=20 > - providing hosts with specific link layer 3 parameters, meaning > parameters that may be incorrect, irrelevant and unrelated on a > different link, and shouldn't be made available on a different link > (if the values are the same across different links, they are different > instances of the values that happen to be the same value) >=20 > - providing hosts with upper layer parameters that are not specific to > and independent of the link the host is currently attached to >=20 > RA options, with exception to the RDNSS options, all solve the first > problem, and it is right that a local device attached to the link > provides the parameters for the link. Address assignment is a link > specific subset problem, so providing link layer specific parameters > to suit address generation/assignment on the link is also solving this > problem. >=20 > DHCPv6 options, with exception to the IA_NA/IA_TA options, all solve > the second problem, and since they're not link specific, and can be > host specific, it means that regardless of where the host attaches, it > isn't a requirement that the device providing them resides on the same > link as the host, as long as the configuration request messages from > the host can reach the configuration server (which we solve with an > on-link DHCPv6 relay). That's not always true. For example the NTP server advertised though = DHCPv6 might only be reachable from that specific link. Same for DNS = servers, AFTR, MAP settings and other options. So there are definitely = exceptions. I love the original model of RA for network stuff and stateless DHCPv6 = for everything else. For new people it took some getting used to, but it = was a clear conceptual model. But for example the push for RDNSS and = DHCPv6 default gateway, DS-Lite and MAP options shows that there is a = demand for more diversity in both directions. So maybe we should take a step back and think about the conceptual model = again. That's all I'm suggesting. I think having two different protocols = (RA and stateless DHCPv6) that are starting to overlap more and more is = a bad thing. Maybe it's time to see if we can define a new conceptual = model where we combine the two... Is there really such a difference between layer-3 settings (RA) and = layer-4+ settings (DHCPv6) that we need to keep those protocols = separate? Or do we need one set of protocols for layer-3+ with both a = multicast-push model (RA) and a unicast-pull model (DHCPv6)? It's a = different conceptual model, so it's not something that can/should be = changed lightly. On the other hand the layer3/4+ distinction seems to be = fading already. But I think it's really important that we revisit this, and rather = sooner than later. I personally am perfectly fine with the original = model, but I also see (mostly) enterprises that seem to push for the = other model and maybe that isn't so bad and we should embrace that and = make it official so we can make it consistent... Cheers, Sander --Apple-Mail=_75CC85B4-7BB5-4851-AF95-F1CBB97879AA Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFSDCCBUQw ggMsoAMCAQICARMwDQYJKoZIhvcNAQEFBQAwdjELMAkGA1UEBhMCTkwxEjAQBgNVBAcTCUFwZWxk b29ybjEVMBMGA1UEChMMU0pNIFN0ZWZmYW5uMR0wGwYDVQQDExRTSk0gU3RlZmZhbm4gUm9vdCBD QTEdMBsGCSqGSIb3DQEJARYOY2FAc3RlZmZhbm4ubmwwHhcNMTUwNTExMDg1MjM1WhcNMTgwODIz MDg1MjM1WjB1MQswCQYDVQQGEwJOTDESMBAGA1UEBxMJQXBlbGRvb3JuMRUwEwYDVQQKEwxTSk0g U3RlZmZhbm4xGDAWBgNVBAMTD1NhbmRlciBTdGVmZmFubjEhMB8GCSqGSIb3DQEJARYSc2FuZGVy QHN0ZWZmYW5uLm5sMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC9b7oVFaA35FKgKq2dZXbh X1kQl2mgPnaI3OurSyefZ6dyv8JFNM6CAA77kb/Gh5FXVDEJujcRPnE93Lmvmx+82J140WSiTpez 7QY8oBYNDCRP0KksXzwfClZjrG2Afw8S1jH14ymK0HufZ9kEkSWD5WzrxEDSqwnQTyFhsGCrbQID AQABo4IBYDCCAVwwCQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBLAwKwYJYIZIAYb4QgENBB4W HFRpbnlDQSBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFMBr5zy4rYkQJ/JeoU3+6lnw Ebd5MIGoBgNVHSMEgaAwgZ2AFOH79lsAHFEBG+6Vrq192mCYPEg6oXqkeDB2MQswCQYDVQQGEwJO TDESMBAGA1UEBxMJQXBlbGRvb3JuMRUwEwYDVQQKEwxTSk0gU3RlZmZhbm4xHTAbBgNVBAMTFFNK TSBTdGVmZmFubiBSb290IENBMR0wGwYJKoZIhvcNAQkBFg5jYUBzdGVmZmFubi5ubIIJALBR3gny oySYMBkGA1UdEgQSMBCBDmNhQHN0ZWZmYW5uLm5sMB0GA1UdEQQWMBSBEnNhbmRlckBzdGVmZmFu bi5ubDALBgNVHQ8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBAFhAYYTBnxV8QzZPT+qs+WLWNRKL 4JQq0dpmSleofioAUrHj8m2BITvJY1pnIY7mdegJXic6+/uCKMAG8FrA6tSNu/hUoTXYMVcUUih5 xZyCWsIFmSBbTuel0nmPvZDayelIwi7GDN0u9IvrmyinSiYJ5jjgiKg3Z1HmMP5t9MR8vpS38bxT WKef8RlACK9jeynmk2U8PFRT+ZVYDW3Us8z4wje+g+q0aEm8UZzoYE245C6aFBqiXS56AN9VcK2C 9Z4wSBnq+I0wRof0BIYIh7V1cFCtz3uhdcbVbfKPHP2GGv69nz/jqSz9hPbIEhC3/kv11FHvIA2x t1scHJOw5DPKaogCtp4BEiOayepZRYo8SCILVTUH07QEP+6D/nLQnNavQT2ClQaSq9ufuD689TvC r5BApB8glktKaPzsiW5gQncIp4GyY593cGkBdh2jPAVpYCyAG96xtY6E0NsjgoghSojeHRfaZOmR iDfaszo4JlIer+VPTcsIl984275cOE/LJcXLSb3AA9AyffEr+6Eszs6HzkfWlzdTedGbqPFhkSlg gBCTZAz/MCT//MVZiDq542xAU8nBpfKWfOyL3oK2PPQAGdpGxFNRzCBngi64n0mB+JrNS44j6WyP qWp2IGSu05o7x6lcUgsjtNmpYvZy4NoyPu4je4+QuzBpFYgCMYICnjCCApoCAQEwezB2MQswCQYD VQQGEwJOTDESMBAGA1UEBxMJQXBlbGRvb3JuMRUwEwYDVQQKEwxTSk0gU3RlZmZhbm4xHTAbBgNV BAMTFFNKTSBTdGVmZmFubiBSb290IENBMR0wGwYJKoZIhvcNAQkBFg5jYUBzdGVmZmFubi5ubAIB EzAJBgUrDgMCGgUAoIIBeTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzAxMTkwOTUwMDRaMCMGCSqGSIb3DQEJBDEWBBSGzUJAT65AWfSBgcliRvlEhaPjXDCBigYJ KwYBBAGCNxAEMX0wezB2MQswCQYDVQQGEwJOTDESMBAGA1UEBxMJQXBlbGRvb3JuMRUwEwYDVQQK EwxTSk0gU3RlZmZhbm4xHTAbBgNVBAMTFFNKTSBTdGVmZmFubiBSb290IENBMR0wGwYJKoZIhvcN AQkBFg5jYUBzdGVmZmFubi5ubAIBEzCBjAYLKoZIhvcNAQkQAgsxfaB7MHYxCzAJBgNVBAYTAk5M MRIwEAYDVQQHEwlBcGVsZG9vcm4xFTATBgNVBAoTDFNKTSBTdGVmZmFubjEdMBsGA1UEAxMUU0pN IFN0ZWZmYW5uIFJvb3QgQ0ExHTAbBgkqhkiG9w0BCQEWDmNhQHN0ZWZmYW5uLm5sAgETMA0GCSqG SIb3DQEBAQUABIGAhXTLND/SfyOhUibcSo7XwzBHGOhVAumfpaP9Iyh7ml1vaEKbVbtDCywCqR8E B7Dhhd//1WS4J6pUlnTylQ2t18r7BUqyPqMxz7ZWgx+dlJ83vdPWIE/8V9YqhUoAAg+zdr3+w89J 1vLboCDfNXQu1nxheWiQdV8JfYAVa0Hs33gAAAAAAAA= --Apple-Mail=_75CC85B4-7BB5-4851-AF95-F1CBB97879AA-- From nobody Thu Jan 19 04:53:33 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 580BE129490 for ; Thu, 19 Jan 2017 04:53:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.501 X-Spam-Level: X-Spam-Status: No, score=-7.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wpi.edu 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 90fbt2izZA-v for ; Thu, 19 Jan 2017 04:53:30 -0800 (PST) Received: from MAIL1.WPI.EDU (mail1.wpi.edu [130.215.36.91]) by ietfa.amsl.com (Postfix) with ESMTP id A2C3612943A for ; Thu, 19 Jan 2017 04:53:30 -0800 (PST) Received: from MAIL1.WPI.EDU (MAIL1.WPI.EDU [130.215.36.91]) by MAIL1.WPI.EDU (8.15.1/8.15.1) with ESMTP id v0JCrStp015546; Thu, 19 Jan 2017 07:53:28 -0500 DKIM-Filter: OpenDKIM Filter v2.10.3 MAIL1.WPI.EDU v0JCrStp015546 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wpi.edu; s=_dkim; t=1484830408; bh=u6OlaTiBXKCBtJ3mu5hBu7LbVFX6ZqeUf4Gj094RJ2o=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=uFdKXIvNzCkXHxoCXfnVqQjFPrvxglyamAISSB+oBujU9V75IWZ/slG/aAvHytRWH sCtmRJXNsnI7mDHwvddrzs1T9LcDFkpS92aL1xdm4qMCSOFizOEXTqwwsIDc8ZWWOZ v5ts79AfSedWshMjGedlnSbx9AgeShwD/OqjkiDQ= Received: from milter1.wpi.edu (milter1.wpi.edu [130.215.36.49]) by MAIL1.WPI.EDU (8.15.1/8.15.1) with ESMTP id v0JCrSN3015543; Thu, 19 Jan 2017 07:53:28 -0500 Received: from angus.ind.wpi.edu (angus.ind.wpi.edu [130.215.130.21]) by milter1.wpi.edu (8.14.4/8.14.4) with ESMTP id v0JChaXd031291; Thu, 19 Jan 2017 07:43:36 -0500 (envelope-from cra@WPI.EDU) Received: by angus.ind.wpi.edu (Postfix, from userid 10002) id 265A4DFB3F; Thu, 19 Jan 2017 07:43:36 -0500 (EST) Date: Thu, 19 Jan 2017 07:43:36 -0500 From: Chuck Anderson To: Mark Smith Message-ID: <20170119124335.GN1862@angus.ind.wpi.edu> References: <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <20170117.170305.74705723.sthaug@nethelp.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-PerlMx-Spam: Gauge=IIIIIIII, Probability=8%, Report=' MULTIPLE_RCPTS 0.1, HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1200_1299 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, FROM_EDU_TLD 0, IN_REP_TO 0, LEGITIMATE_SIGNS 0, MSG_THREAD 0, MULTIPLE_REAL_RCPTS 0, NO_CTA_URI_FOUND 0, NO_URI_FOUND 0, NO_URI_HTTPS 0, REFERENCES 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CC_NAME 0, __CC_NAME_DIFF_FROM_ACC 0, __CC_REAL_NAMES 0, __CD 0, __CT 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __HAS_CC_HDR 0, __HAS_FROM 0, __HAS_MSGID 0, __IN_REP_TO 0, __MIME_TEXT_ONLY 0, __MIME_TEXT_P 0, __MIME_TEXT_P1 0, __MIME_VERSION 0, __MULTIPLE_RCPTS_CC_X2 0, __NO_HTML_TAG_RAW 0, __PHISH_PHRASE3 0, __PHISH_SPEAR_STRUCTURE_1 0, __REFERENCES 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __SUBJ_ALPHA_NEGATE 0, __TO_MALFORMED_2 0, __TO_NAME 0, __TO_NAME_DIFF_FROM_ACC 0, __TO_REAL_NAMES 0, __USER_AGENT 0' Archived-At: Cc: Fernando Gont , v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 12:53:32 -0000 On Wed, Jan 18, 2017 at 10:29:16AM +1100, Mark Smith wrote: > On 18 January 2017 at 09:57, Brian E Carpenter > > Many campuses want to use DHCPv6 for address assignment, however. > > So I am always interested to know what problem they're trying to solve > then they say that. I expect it is address use/auditability for > security purposes. I then wonder if they've put in place companion > measures to prevent hosts from using addresses configured statically, > or measures to prevent an entirely new prefix being brought up on the > link by hosts via static configuration, that won't be recorded in the > DHCPv6 address database. Yes, we use DHCP Snooping, Dyanamic ARP Inspection, IP Source Guard, and strict Unicast Reverse Path Filtering to make sure no one can bypass the address assignments made by the DHCPv4 server. We probably would have deployed IPv6 by now if we could solve the address use auditability challenges. We've mostly given up on the dual-stack DNS synchronization idea and will probably accept that the IPv6 address(es) assigned for non-server hosts will not have any AAAA or PTR records, even though we do provide A and PTR records for all IPv4 addresses on all hosts. From nobody Thu Jan 19 05:43:41 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 212711295DE for ; Thu, 19 Jan 2017 05:43:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.501 X-Spam-Level: X-Spam-Status: No, score=-7.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wpi.edu 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 lggXbHPmq3Ji for ; Thu, 19 Jan 2017 05:43:32 -0800 (PST) Received: from MAIL1.WPI.EDU (mail1.wpi.edu [130.215.36.91]) by ietfa.amsl.com (Postfix) with ESMTP id 2E4821295D7 for ; Thu, 19 Jan 2017 05:43:30 -0800 (PST) Received: from MAIL1.WPI.EDU (MAIL1.WPI.EDU [130.215.36.91]) by MAIL1.WPI.EDU (8.15.1/8.15.1) with ESMTP id v0JDhSGt004357; Thu, 19 Jan 2017 08:43:28 -0500 DKIM-Filter: OpenDKIM Filter v2.10.3 MAIL1.WPI.EDU v0JDhSGt004357 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wpi.edu; s=_dkim; t=1484833408; bh=igN0yPtWXTTTyycfwebFJiiwjcIZHOMWqA+uPMUOkes=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=IhKqGQsolf9oyts2++dSf/+tl3A2NPSUiA0mkBrnPsXpfuDaakl5xxO+UkC4hE544 DC2jHCZiUC6p8hmvGl03Rqu3XZIal0B0kVmT5+RQUMpO56/bYcabCB5dpzOY4hX2Ty 1rNfVrtuu5BKKJoP5oqYbuKCsVXO6ybjQvseoRxo= Received: from milter1.wpi.edu (milter1.wpi.edu [130.215.36.49]) by MAIL1.WPI.EDU (8.15.1/8.15.1) with ESMTP id v0JDhSxn004352; Thu, 19 Jan 2017 08:43:28 -0500 Received: from angus.ind.wpi.edu (angus.ind.wpi.edu [130.215.130.21]) by milter1.wpi.edu (8.14.4/8.14.4) with ESMTP id v0JDSavf022389; Thu, 19 Jan 2017 08:28:37 -0500 (envelope-from cra@WPI.EDU) Received: by angus.ind.wpi.edu (Postfix, from userid 10002) id 8462BDFB3F; Thu, 19 Jan 2017 08:28:36 -0500 (EST) Date: Thu, 19 Jan 2017 08:28:36 -0500 From: Chuck Anderson To: Lorenzo Colitti Message-ID: <20170119132836.GO1862@angus.ind.wpi.edu> References: <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <20170117.170305.74705723.sthaug@nethelp.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-PerlMx-Spam: Gauge=IIIIIIII, Probability=8%, Report=' MULTIPLE_RCPTS 0.1, HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_2000_2999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, FROM_EDU_TLD 0, IN_REP_TO 0, LEGITIMATE_SIGNS 0, MSG_THREAD 0, MULTIPLE_REAL_RCPTS 0, NO_URI_HTTPS 0, REFERENCES 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CC_NAME 0, __CC_NAME_DIFF_FROM_ACC 0, __CC_REAL_NAMES 0, __CD 0, __CT 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __FRAUD_BODY_WEBMAIL 0, __FRAUD_WEBMAIL 0, __HAS_CC_HDR 0, __HAS_FROM 0, __HAS_MSGID 0, __IN_REP_TO 0, __MIME_TEXT_ONLY 0, __MIME_TEXT_P 0, __MIME_TEXT_P1 0, __MIME_VERSION 0, __MULTIPLE_RCPTS_CC_X2 0, __NO_HTML_TAG_RAW 0, __PHISH_SPEAR_STRUCTURE_1 0, __REFERENCES 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __SUBJ_ALPHA_NEGATE 0, __TO_MALFORMED_2 0, __TO_NAME 0, __TO_NAME_DIFF_FROM_ACC 0, __TO_REAL_NAMES 0, __URI_NO_WWW 0, __URI_NS , __USER_AGENT 0' Archived-At: Cc: Fernando Gont , v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 13:43:33 -0000 On Wed, Jan 18, 2017 at 04:16:19PM +0900, Lorenzo Colitti wrote: > On Wed, Jan 18, 2017 at 1:52 AM, Mark Smith wrote: > > > DHCPv6 is more capable, flexible and general purpose. > > > > In many ways it actually isn't more capable. In particular, > > - It is very difficult or impossible to change anything. In theory, > there's reconfigure. In practice, nobody implements that, even when it is > mandatory. (In the immortal words of Steven Barth, lead OpenWRT developer, > "home gateways are supposed to MUST" implement reconfigure.) In contrast, > RAs are fundamentally dynamic. And yet we've been willing to live with that limitation in DHCPv4. We set lease times appropriately and know that we have to plan ahead for any necessary changes by lowering lease times in advance, etc. There is also the fact that many devices will do a DHCP transaction upon link status change, so often that can be used as a way to cause them to reconfigure. My understanding is that RAs also have a lifetime field and one would run into the same type of advance planning requirement there as well. > - It is very difficult to have multiple sources of information. In > theory it's possible to get multiple OFFERs and select more than one of > them, but I think common clients don't implement this. Wait, wouldn't this be a benefit? The draft under discussion points out the problems with having overlapping information. > - It is impossible to add a new source of information once the client > has a lease, because there's no push mechanism. Even if reconfigure were > implemented, which it isn't, only the original server can reconfigure > because it's the only one that the client trusts. RAs > - If the server crashes or is unplugged, there is no way to update the > client because only the server can reconfigure the client. So? If the router (which runs RA) crashes, the client can't even get out of the subnet. You can have multiple DHCP servers for redundancy, just as you can have multiple routers for redundancy. There is a failover protocol defined for DHCPv4 and the DHCPv6 one is in progress. > All these make DHCPv6 a rather bad idea for networks that change without > advance warning, such as home networks. Fine, but that doesn't mean we should ignore enterprise networks. > The only reason we don't have these problems in IPv4 is that in IPv4 we > have NAT (which means the clients never need to change their IP address on > demand) and VRRP. It would be nice not to need NAT, at least. My enterprise IPv4 network has never run NAT and we don't have these problems in IPv4. We've needed to change IP addressing information on many occasions and managed to do this with just DHCPv4. Maybe it is precisely because we don't run NAT that we are having such a difficult time accepting the lack of functionality in IPv6. From nobody Thu Jan 19 06:18:38 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F27B1295D4 for ; Thu, 19 Jan 2017 06:18:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 ZbUdC3CwzuJZ for ; Thu, 19 Jan 2017 06:18:35 -0800 (PST) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5035A129415 for ; Thu, 19 Jan 2017 06:18:35 -0800 (PST) Received: by mail-vk0-x22a.google.com with SMTP id x75so30935426vke.2 for ; Thu, 19 Jan 2017 06:18:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hlnmUa/K0Ju9B3BZBVmG5nUH2ZT+TNKLGTJjAMocHX8=; b=sRtktK421cuNbRmOrG3S1WgdBxr85pDPLrGIR+TGLwEBScID1kTtApXARdBwOyhzuR 1uuvm+KbEs+AQITn+f0HsVWHmK9XsIUPBkhDFtgSl62UH830lFwhUo24mpQ4DUzkDRk6 zC9kRT/nVYyF7RBJaA+3kQPvhQ1wySjm8dqnpUjBHYTP0a0TSOTMjNj5CC8ipiGyUFk2 F4p3kChzJJ4p4crCdiIL+UzIvZfoKc8K/emwpZgEujrhU0I86Ovob+gDOskiTGInm1Ur QkOQ/kroAU9FDYjanISCcbN88x9u2zFGQyHyZmbSqNFykKCI8I+nbTFn2Svf1QQ7xvly Giww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hlnmUa/K0Ju9B3BZBVmG5nUH2ZT+TNKLGTJjAMocHX8=; b=IwTmZU769ODOWs3M0Il1wUucJhoNYQdEeCKvDVsg8YI/gYFZLF781tIJqM3TCY/tNc SIWMxa3tW9TMe07V+aadsZsZ5BvjL5lqHF9LJtzKBjugvYqP5Kq0+UrTh8puznFcAUH4 +EmsmGSU8VHHJQm7roJShlJXwSfdeLkzGevjZvJN6fEKbW4l6mC9SdFnhRdgN/xXbQt2 RUhDqAu+2vEn9PSVsuGPFFOfTob6g9/tAOcu7rEDM9Z6WYSyumaIFwinqWwhg5rumZBh h78ILBtuY56ZKKbPoQuf4szSzOUspMePXM63BV9+jTtt4iEZK0vUylBfASJQBGTw+vOo QoQQ== X-Gm-Message-State: AIkVDXJmeAG/Sep1meWCs+8a63fBpqM1qupE3QkJC4z+K3vTBIlTN9EyyS+bujaLDPZQ4aYcTXyhbPKbCRJri0Fw X-Received: by 10.31.150.134 with SMTP id y128mr3892516vkd.102.1484835514178; Thu, 19 Jan 2017 06:18:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.171.2 with HTTP; Thu, 19 Jan 2017 06:18:13 -0800 (PST) In-Reply-To: <20170119132836.GO1862@angus.ind.wpi.edu> References: <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <20170117.170305.74705723.sthaug@nethelp.no> <20170119132836.GO1862@angus.ind.wpi.edu> From: Lorenzo Colitti Date: Thu, 19 Jan 2017 23:18:13 +0900 Message-ID: To: Chuck Anderson Content-Type: multipart/alternative; boundary=001a1141d6005fe46c05467335b6 Archived-At: Cc: Fernando Gont , v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 14:18:37 -0000 --001a1141d6005fe46c05467335b6 Content-Type: text/plain; charset=UTF-8 On Thu, Jan 19, 2017 at 10:28 PM, Chuck Anderson wrote: > And yet we've been willing to live with that limitation in DHCPv4. We > set lease times appropriately and know that we have to plan ahead for > any necessary changes by lowering lease times in advance, etc. There > is also the fact that many devices will do a DHCP transaction upon > link status change, so often that can be used as a way to cause them > to reconfigure. > But you still can't change things in a non-disruptive way at any time. You have to wait for the hosts to ask again, or disrupt their connectivity. An example of what you can't do is tell the host that some of its addresses is now unable to reach the Internet, such as you might want to do if you do multihoming without BGP and one of the uplinks goes down. > My understanding is that RAs also have a lifetime field and one would > run into the same type of advance planning requirement there as well. > No, you can update information at any time by sending a new RA. > - It is very difficult to have multiple sources of information. In > > theory it's possible to get multiple OFFERs and select more than one > of > > them, but I think common clients don't implement this. > > Wait, wouldn't this be a benefit? It only works at all if there is a central configuration authority in the network. This is not the case in a home network which has uplinks to two different ISPs. > The draft under discussion points out the problems with having overlapping information. > Overlapping information is a problem if there are conflicts. If the information received by the host is the same regardless of the method it receives it through, the end result is the same. > > - If the server crashes or is unplugged, there is no way to update the > > client because only the server can reconfigure the client. > > So? If the router (which runs RA) crashes, the client can't even get > out of the subnet. But you can a new router online can come online and continue to provide service. You can't do that with DHCP because nothing can change until the lease expires or there's a disruption. > You can have multiple DHCP servers for redundancy, > just as you can have multiple routers for redundancy. There is a > failover protocol defined for DHCPv4 and the DHCPv6 one is in > progress. > Actually, the situation is not so much that you *can* have multiple servers. The situation is that if you want redundancy, you *have to* have multiple servers that have to talk to each other, because the client will pick one. Again, that works in a very actively managed network, but not in a > > All these make DHCPv6 a rather bad idea for networks that change without > > advance warning, such as home networks. > > Fine, but that doesn't mean we should ignore enterprise networks. > The assertion was that DHCPv6 is a superior protocol. I'm pointing out that in several ways it's actually not a very good one, and that a lot of us don't even see those ways because we simply take for granted that a client-pull model based on fix lease times is the the only way clients obtain network configuration. > > The only reason we don't have these problems in IPv4 is that in IPv4 we > > have NAT (which means the clients never need to change their IP address > on > > demand) and VRRP. It would be nice not to need NAT, at least. > > My enterprise IPv4 network has never run NAT and we don't have these > problems in IPv4. We've needed to change IP addressing information on > many occasions and managed to do this with just DHCPv4. Maybe it is > precisely because we don't run NAT that we are having such a difficult > time accepting the lack of functionality in IPv6. > So you provide end-to-end-connectivity over IPv4? Wow. That practice is sadly mostly consigned to the past; most networks can't afford it any more. So consider this: if you want end-to-end, and you want connectivity that's robust in the face of ISP outages, then you have exactly two choices: 1. ensure the host's IP address never changes (e.g., by doing BGP multihoming), or 2. ensure that you can change the host's IP address when its previous IP address is no longer reachable. #1 works great if you can afford it, but it doesn't scale because typically the way we do it is BGP. If you can't do #1, then you need a way to change hosts's IP addresses without advance notice when something bad happens. You can't do that via DHCP. If you use RAs, you can simultaneously announce and use two prefixes, and when one of them stops working, you can deprecate it immediately. --001a1141d6005fe46c05467335b6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jan 19, 2017 at 10:28 PM, Chuck Anderson <cra@wpi.edu> wrote:=
And yet we've been willing to live w= ith that limitation in DHCPv4.=C2=A0 We
set lease times appropriately and know that we have to plan ahead for
any necessary changes by lowering lease times in advance, etc.=C2=A0 There<= br> is also the fact that many devices will do a DHCP transaction upon
link status change, so often that can be used as a way to cause them
to reconfigure.

But you still can't= change things in a non-disruptive way at any time. You have to wait for th= e hosts to ask again, or disrupt their connectivity. An example of what you= can't do is tell the host that some of its addresses is now unable to = reach the Internet, such as you might want to do if you do multihoming with= out BGP and one of the uplinks goes down.
=C2=A0
My understanding is that RAs also have a lifetime field and one would
run into the same type of advance planning requirement there as well.

No, you can update information at any time b= y sending a new RA.

>=C2=A0 =C2=A0 - It is very difficult to have multiple sources of inform= ation. In
>=C2=A0 =C2=A0 theory it's possible to get multiple= OFFERs and select more than one of
>=C2=A0 =C2=A0 them, but I think common clients don't implement this= .

Wait, wouldn't this be a benefit?

It only works at all if there is a central configuration authority in the= network. This is not the case in a home network which has uplinks to two d= ifferent ISPs.
=C2=A0
The dra= ft under discussion points
out the problems with having overlapping information.
=
Overlapping information is a problem if there are conflicts.= If the information received by the host is the same regardless of the meth= od it receives it through, the end result is the same.
=C2=A0
>=C2=A0 =C2=A0 - If the server crashes = or is unplugged, there is no way to update the
>=C2=A0 =C2=A0 client because only the server can recon= figure the client.

So?=C2=A0 If the router (which runs RA) crashes, the client can'= t even get
out of the subnet.

But you can a new router= online can come online and continue to provide service. You can't do t= hat with DHCP because nothing can change until the lease expires or there&#= 39;s a disruption.
=C2=A0
=C2= =A0 You can have multiple DHCP servers for redundancy,
just as you can have multiple routers for redundancy.=C2=A0 There is a
failover protocol defined for DHCPv4 and the DHCPv6 one is in
progress.

Actually, the situation is no= t so much that you *can* have multiple servers. The situation is that if yo= u want redundancy, you *have to* have multiple servers that have to talk to= each other, because the client will pick one. Again, that works in a very = actively managed network, but not in a=C2=A0
=C2=A0
> All these make DHCPv6 a rather bad idea for networks that change witho= ut
> advance warning, such as home networks.

Fine, but that doesn't mean we should ignore enterprise networks= .

The assertion was that DHCPv6 is a su= perior protocol. I'm pointing out that in several ways it's actuall= y not a very good one, and that a lot of us don't even see those ways b= ecause we simply take for granted that a client-pull model based on fix lea= se times is the the only way clients obtain network configuration.
=C2=A0
> The only reason we don't have these problems in IPv4 is that in IP= v4 we
> have NAT (which means the clients never need to change their IP addres= s on
> demand) and VRRP. It would be nice not to need NAT, at least.

My enterprise IPv4 network has never run NAT and we don't have t= hese
problems in IPv4.=C2=A0 We've needed to change IP addressing informatio= n on
many occasions and managed to do this with just DHCPv4.=C2=A0 Maybe it is precisely because we don't run NAT that we are having such a difficult<= br> time accepting the lack of functionality in IPv6.

So you provide end-= to-end-connectivity over IPv4? Wow. That practice is sadly mostly consigned= to the past; most networks can't afford it any more. So consider this:= if you want end-to-end, and you want connectivity that's robust in the= face of ISP outages, then you have exactly two choices: 1. ensure the host= 's IP address never changes (e.g., by doing BGP multihoming), or 2. ens= ure that you can change the host's IP address when its previous IP addr= ess is no longer reachable.

<= div class=3D"gmail_extra">#1 works great if you can afford it, but it doesn= 't scale because typically the way we do it is BGP. If you can't do= #1, then you need a way to change hosts's IP addresses without advance= notice when something bad happens. You can't do that via DHCP. If you = use RAs, you can simultaneously announce and use two prefixes, and when one= of them stops working, you can deprecate it immediately.
--001a1141d6005fe46c05467335b6-- From nobody Thu Jan 19 07:50:00 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE30129460 for ; Thu, 19 Jan 2017 07:49:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=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 3z9fNfkQaSK5 for ; Thu, 19 Jan 2017 07:49:57 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 5610512945A for ; Thu, 19 Jan 2017 07:49:56 -0800 (PST) Received: from stereo.hq.phicoh.net ([::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #127) id m1cUEyI-0000DhC; Thu, 19 Jan 2017 16:49:54 +0100 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bF054DD66@u-1.phicoh.com References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <99204933-5CB6-4E89-BD6A-FD40136DF6F5@steffann.nl> In-reply-to: Your message of "Thu, 19 Jan 2017 10:50:04 +0100 ." Date: Thu, 19 Jan 2017 16:49:53 +0100 Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 15:49:59 -0000 In your letter dated Thu, 19 Jan 2017 10:50:04 +0100 you wrote: >So maybe we should take a step back and think about the conceptual model >again. That's all I'm suggesting. I think having two different protocols >(RA and stateless DHCPv6) that are starting to overlap more and more is >a bad thing. Maybe it's time to see if we can define a new conceptual >model where we combine the two... The problem I see is that lack of a standards track RFC that basically says 'a host MUST implement support for both SLAAC and statefull DHCPv6' That's where we went wrong. No idea if we can fix it. How a network is configured should upto the local network and system administrators. Leaving out support for either of SLAAC of DHCPv6 in a host makes life hard for no reason. In the past tiny devices had no problem implementing DHCP for IPv4. To the extend that SLAAC and stateless DHCPv6 require extra code, that's a pity. But it is not that much code that it warrants creating the current complexity where networks have to support both DHCPv6 and SLAAC. From nobody Thu Jan 19 08:05:22 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F7DF1294A0 for ; Thu, 19 Jan 2017 08:05:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.799 X-Spam-Level: X-Spam-Status: No, score=-5.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=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 eWgO0XMIC673 for ; Thu, 19 Jan 2017 08:05:18 -0800 (PST) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BC9312896F for ; Thu, 19 Jan 2017 08:05:16 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id E7F8B600FB for ; Thu, 19 Jan 2017 17:05:14 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id A6312600FA; Thu, 19 Jan 2017 17:05:14 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id A344123EAD; Thu, 19 Jan 2017 17:05:14 +0100 (CET) Date: Thu, 19 Jan 2017 17:05:14 +0100 From: Gert Doering To: Philip Homburg Message-ID: <20170119160514.GD48971@Space.Net> References: <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <99204933-5CB6-4E89-BD6A-FD40136DF6F5@steffann.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.7.1 (2016-10-04) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 16:05:20 -0000 Hi, On Thu, Jan 19, 2017 at 04:49:53PM +0100, Philip Homburg wrote: > The problem I see is that lack of a standards track RFC that basically says > 'a host MUST implement support for both SLAAC and statefull DHCPv6' > > That's where we went wrong. No idea if we can fix it. > > How a network is configured should upto the local network and system > administrators. Leaving out support for either of SLAAC of DHCPv6 in a host > makes life hard for no reason. This brings, what, 50+? mails nicely to the point. (And for a change, I agree with Philip, though that should maybe read "SLAAC+RDNSS" up there, given that really everybody supports *SLAAC* today) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Thu Jan 19 08:52:57 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE59412943D for ; Thu, 19 Jan 2017 08:52:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.501 X-Spam-Level: X-Spam-Status: No, score=-7.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wpi.edu 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 lPIyxQs3m5Wm for ; Thu, 19 Jan 2017 08:52:54 -0800 (PST) Received: from MAIL1.WPI.EDU (mail1.wpi.edu [130.215.36.91]) by ietfa.amsl.com (Postfix) with ESMTP id 141AB129477 for ; Thu, 19 Jan 2017 08:52:53 -0800 (PST) Received: from MAIL1.WPI.EDU (MAIL1.WPI.EDU [130.215.36.91]) by MAIL1.WPI.EDU (8.15.1/8.15.1) with ESMTP id v0JGqnrx022957; Thu, 19 Jan 2017 11:52:49 -0500 DKIM-Filter: OpenDKIM Filter v2.10.3 MAIL1.WPI.EDU v0JGqnrx022957 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wpi.edu; s=_dkim; t=1484844769; bh=xFSOm7283g1i7ESiDr+jBmSoW4010eRex91ULDbzp+s=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=itLG1dPyTvdJXWAtPWKu6UnRG6ucD1TaTZZsJLUamjzBX/Lh9+S3b8V7GbobNIH9J S78GktRzlVLRe2z0lZgld+Dj+udbXAHCnHCIe3mHAn5X8WI7NkZF9FwBGi3YPp4CJd 8BN3up8b0Gpn0MNfbKANgkMci2U3KLBrXS+qlYdk= Received: from milter1.wpi.edu (milter1.wpi.edu [130.215.36.49]) by MAIL1.WPI.EDU (8.15.1/8.15.1) with ESMTP id v0JGqnuM022953; Thu, 19 Jan 2017 11:52:49 -0500 Received: from angus.ind.wpi.edu (angus.ind.wpi.edu [130.215.130.21]) by milter1.wpi.edu (8.14.4/8.14.4) with ESMTP id v0JGqmQQ019486; Thu, 19 Jan 2017 11:52:48 -0500 (envelope-from cra@WPI.EDU) Received: by angus.ind.wpi.edu (Postfix, from userid 10002) id 1B0BFDFB3F; Thu, 19 Jan 2017 11:52:48 -0500 (EST) Date: Thu, 19 Jan 2017 11:52:48 -0500 From: Chuck Anderson To: Lorenzo Colitti Message-ID: <20170119165247.GV2891@angus.ind.wpi.edu> References: <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <20170117.170305.74705723.sthaug@nethelp.no> <20170119132836.GO1862@angus.ind.wpi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-PerlMx-Spam: Gauge=IIIIIIII, Probability=8%, Report=' MULTIPLE_RCPTS 0.1, HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1200_1299 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, FROM_EDU_TLD 0, IN_REP_TO 0, LEGITIMATE_SIGNS 0, MSG_THREAD 0, MULTIPLE_REAL_RCPTS 0, NO_CTA_URI_FOUND 0, NO_URI_FOUND 0, NO_URI_HTTPS 0, REFERENCES 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CC_NAME 0, __CC_NAME_DIFF_FROM_ACC 0, __CC_REAL_NAMES 0, __CD 0, __CT 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __HAS_CC_HDR 0, __HAS_FROM 0, __HAS_MSGID 0, __IN_REP_TO 0, __MIME_TEXT_ONLY 0, __MIME_TEXT_P 0, __MIME_TEXT_P1 0, __MIME_VERSION 0, __MULTIPLE_RCPTS_CC_X2 0, __NO_HTML_TAG_RAW 0, __PHISH_SPEAR_STRUCTURE_1 0, __REFERENCES 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __SUBJ_ALPHA_NEGATE 0, __TO_MALFORMED_2 0, __TO_NAME 0, __TO_NAME_DIFF_FROM_ACC 0, __TO_REAL_NAMES 0, __USER_AGENT 0' Archived-At: Cc: Fernando Gont , v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 16:52:55 -0000 On Thu, Jan 19, 2017 at 11:18:13PM +0900, Lorenzo Colitti wrote: > So you provide end-to-end-connectivity over IPv4? Wow. That practice is > sadly mostly consigned to the past; most networks can't afford it any more. > So consider this: if you want end-to-end, and you want connectivity that's > robust in the face of ISP outages, then you have exactly two choices: 1. > ensure the host's IP address never changes (e.g., by doing BGP > multihoming), or 2. ensure that you can change the host's IP address when > its previous IP address is no longer reachable. > > #1 works great if you can afford it, but it doesn't scale because typically > the way we do it is BGP. If you can't do #1, then you need a way to change > hosts's IP addresses without advance notice when something bad happens. You > can't do that via DHCP. If you use RAs, you can simultaneously announce and > use two prefixes, and when one of them stops working, you can deprecate it > immediately. Okay, so all your arguments above are working under the assumption that RA-based site multihoming can actually work in the real world. There are many practical problems with that approach. Ironically, a possible solution is identified RFC7157, which requires DHCPv6. From nobody Thu Jan 19 09:01:10 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE145129857 for ; Thu, 19 Jan 2017 09:01:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.721 X-Spam-Level: X-Spam-Status: No, score=-17.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 zm0ZbuA8VPmL for ; Thu, 19 Jan 2017 09:01:07 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A06C2129861 for ; Thu, 19 Jan 2017 08:59:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=691; q=dns/txt; s=iport; t=1484845163; x=1486054763; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=YWmmA6ibIzAfmtPnKHseqIAzAAxgb8oqxflJeeA3Tss=; b=R9I9MI3nWh5mvUEEi6xKIrm6a4oBtB9lhdQU4QUlEmkVw0bu37LbGkn9 a2iQ0SGXptvGkgxldYs1uuYXuOKgTr8i+J1RPq1z774nkjLJID048wC8/ K35v57dZnGJk+YGGcLaRLRwf8auLD5iusrYR1liQorwH435Z7sHmWiwTi 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ATAQBA74BY/4wNJK1eDgsBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM/AQEBAQEfgXCNUqcwggyGIgKBfj8YAQIBAQEBAQEBYyiEagY?= =?us-ascii?q?6PxACAQgOKBAyJQIEAQ0NiHuyMIpKAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYs5h?= =?us-ascii?q?CaGBwWbRAGRW5B3km8BHziBRhWGNjuHa4EvgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.33,254,1477958400"; d="scan'208";a="374714225" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Jan 2017 16:59:22 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v0JGxMPm018857 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 19 Jan 2017 16:59:22 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 19 Jan 2017 10:59:22 -0600 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1210.000; Thu, 19 Jan 2017 10:59:22 -0600 From: "Bernie Volz (volz)" To: Chuck Anderson , Lorenzo Colitti Thread-Topic: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem Thread-Index: AdJsHl8eSkgq9pmdSH+a6rrO1byUfgEH4nKAAA8QH4AABHryAAAFi+6AABamygAAAefdAAACPr2AAAG7wYAAHikwgAA/SxMAAAG7nIAABWYVAAAMguqg Date: Thu, 19 Jan 2017 16:59:22 +0000 Message-ID: <50240d7e06c3427cabaac463a95cdac2@XCH-ALN-003.cisco.com> References: <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <20170117.170305.74705723.sthaug@nethelp.no> <20170119132836.GO1862@angus.ind.wpi.edu> <20170119165247.GV2891@angus.ind.wpi.edu> In-Reply-To: <20170119165247.GV2891@angus.ind.wpi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.1.200] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Fernando Gont , v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 17:01:09 -0000 While I probably shouldn't send this as it is in the political and not tech= nical space, I frankly am very disappointed in one company that, while tryi= ng to promote IPv6 usage, has also worked very hard to limit its use by NOT= supporting a protocol developed by the IETF. I'm also surprised that organizations haven't pushed harder to get that com= pany to implement the standards. I suspect though that is because IPv6 is n= ot yet "critical" for deployment. This provides the company an opportunity = to push their agenda (whatever it may be). I will admit that being DHC WG co-chair, coauthor of the some of the standa= rds, and also a vendor does bias me. - Bernie From nobody Thu Jan 19 09:08:33 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47B4B1293F8 for ; Thu, 19 Jan 2017 09:08:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 YcTpBOSYNxJV for ; Thu, 19 Jan 2017 09:08:29 -0800 (PST) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5451129456 for ; Thu, 19 Jan 2017 09:08:29 -0800 (PST) Received: by mail-ua0-x22f.google.com with SMTP id y9so40355770uae.2 for ; Thu, 19 Jan 2017 09:08:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wdZpY2ZGhFgoYDQzdVuaTNrSZEqUc5bQ/yURmny19zo=; b=X0CvkGN9xe9gYknL61mj93zpKEJwACN0162yNMNLk8vbiOQTrwDgLDM3fL5VOkGGe3 rs6zalFC4zU/zx8pABFV2g/pfz9Kzi9b2UkKtDLu3c4ORpgA16C2k9k6Ve02ezuVYioY h0ozWIPgvgyR8vjhxrvsi2JbNzcYf1C8LKhV9env7rihTQw4BUuuUmUR6P/xg+rpIOT0 Hrgiu1UhwP2UGPFwTyapOPRh0llJsGswL+dtBCCzRLaq8bZ2LctZuS5AdllY10TAG6PB 8Li+fHQgCyKt9sk1jSdzoL1Q9M5fB0ny3bgl4AmNGBulqtSoMxgWreI4JlbVpdjaBoB/ 4LEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wdZpY2ZGhFgoYDQzdVuaTNrSZEqUc5bQ/yURmny19zo=; b=XMjl/wSAtNc4YaM2OM+77W4qZeoPTmJbl/d8M+AcWA9hR7PgIOcldWtytOVoPEZWtI I3gQ+ldRQWKwLbIT8Db+vEA715Vb0evOcCHNlsvg/o5M8aLmh7jWgzEuQslELXfKuV+e vIdl28FOHKwROatqyCqzKR/4dl32rJu89XqEaEm2sWP0RC0O5fJlAtRSwSSowWMbAWH4 YP9uDMkdQYr7WbX5F8DV1CWGbkYCIDw2Ik0bwUmqTMwIQphQQ9fHZaYf9huL2b8hAsTz TvZ8FDl1deLb3h0LUIThwo6p0nqQuUYLOzIIQhxezp9ujHSbHP+L/JQgpZXQVtSE+tK4 C5ng== X-Gm-Message-State: AIkVDXJXRXxR8lMU5LoTEneaM42pGOc5eOyLabXnn5bpJvLFzjcT+mOXWXBYsNN8zcwEu8rXzRi92lHPPtdJA5zl X-Received: by 10.176.65.101 with SMTP id j92mr5429163uad.57.1484845708489; Thu, 19 Jan 2017 09:08:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.171.2 with HTTP; Thu, 19 Jan 2017 09:08:07 -0800 (PST) In-Reply-To: <20170119165247.GV2891@angus.ind.wpi.edu> References: <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <20170117.170305.74705723.sthaug@nethelp.no> <20170119132836.GO1862@angus.ind.wpi.edu> <20170119165247.GV2891@angus.ind.wpi.edu> From: Lorenzo Colitti Date: Fri, 20 Jan 2017 02:08:07 +0900 Message-ID: To: Chuck Anderson Content-Type: multipart/alternative; boundary=94eb2c122f9e012f35054675956d Archived-At: Cc: Fernando Gont , v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 17:08:31 -0000 --94eb2c122f9e012f35054675956d Content-Type: text/plain; charset=UTF-8 On Fri, Jan 20, 2017 at 1:52 AM, Chuck Anderson wrote: > Okay, so all your arguments above are working under the assumption > that RA-based site multihoming can actually work in the real world. > It is the only way to do PA-based multihoming without NAT and BGP. > There are many practical problems with that approach. Ironically, a > possible solution is identified RFC7157, which requires DHCPv6. > Meh. draft-bowbakova-rtgwg-enterprise-pa-multihoming-01 is the way to go. --94eb2c122f9e012f35054675956d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Jan 20, 2017 at 1:52 AM, Chuck Anderson <cra@wpi.edu> wrote:=
Okay, so all your arg= uments above are working under the assumption
that RA-based site multihoming can actually work in the real world.

It is the only way to do PA-based multihoming = without NAT and BGP.
=C2=A0
There are many practical problems with that approach.=C2=A0 Ironically, a possible solution is identified RFC7157, which requires DHCPv6.

Meh.=C2=A0draft-bow= bakova-rtgwg-enterprise-pa-multihoming-01 is the way to go.
--94eb2c122f9e012f35054675956d-- From nobody Thu Jan 19 09:24:42 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC882129460 for ; Thu, 19 Jan 2017 09:24:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=steffann.nl 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 I9p_Lx9AstSv for ; Thu, 19 Jan 2017 09:24:39 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F8DD129456 for ; Thu, 19 Jan 2017 09:24:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id D15F24A; Thu, 19 Jan 2017 18:24:36 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:message-id:date:date:in-reply-to:from:from :subject:subject:mime-version:content-type:content-type:received :received; s=mail; t=1484846675; bh=TZYSnlNSEhxiUzALu+DWElR/Lq/2 7tfVwwox2DJvtDk=; b=WiZ4hxTw/w9Ai+E6kQhdjaoiKVW6AI5g4s78ZQWqIJ/V 2XGMZcXlvy7jVH6vagQWfhDI2uDDj7DHqzqO5jzZn65dpk8rtPRoK4qeyz3qCp7O bvxrdx8FoLAQ10nuFOuu51cX4RfjkGIQXB9s11cP0cWELZwR3JbHyERZLkffvy4= X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id UPAH9LUia12P; Thu, 19 Jan 2017 18:24:35 +0100 (CET) Received: from [IPv6:2a02:a213:a300:9300:1cc7:83e8:5c1d:28b0] (unknown [IPv6:2a02:a213:a300:9300:1cc7:83e8:5c1d:28b0]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.sintact.nl (Postfix) with ESMTPSA id 2B6CB48; Thu, 19 Jan 2017 18:24:35 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_91423C09-371B-493C-8133-C8B8A162F8CA"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Clacks-Overhead: GNU Terry Pratchett From: Sander Steffann In-Reply-To: Date: Thu, 19 Jan 2017 18:24:34 +0100 Message-Id: <394A26E7-063E-4A53-83D3-022AA93E4001@steffann.nl> References: <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <20170117.170305.74705723.sthaug@nethelp.no> <20170119132836.GO1862@angus.ind.wpi.edu> <20170119165247.GV2891@angus.ind.wpi.edu> To: Lorenzo Colitti X-Mailer: Apple Mail (2.3124) Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 17:24:41 -0000 --Apple-Mail=_91423C09-371B-493C-8133-C8B8A162F8CA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Lorenzo, > Meh. draft-bowbakova-rtgwg-enterprise-pa-multihoming-01 is the way to = go. Thanks for the reference, that's an interesting read that points out = where we can improve things to make multihoming using PA addresses = without NAT nice to use. And not just in enterprise environments. Cheers, Sander --Apple-Mail=_91423C09-371B-493C-8133-C8B8A162F8CA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJYgPZSAAoJEKAtA7D+JBO5Xa8H/jVnPjB3UJU/vbvMf/jcSsEs +pesTAsQxftsijrCGCJY4oq6O1yjGSXoY01kA8h7+xndhvzHMzg+jaFB09NHWqgd zbHjiarsUmAkm96P6eYRipYG3jP/wh0KHQqB57Al579Xs7IDJ+jYVohZp/w/u5DU JsZeIKfDKF/Q/oAZGQyqlqdvVLF4JUbeX40OJvQwQVRFXnx04h4o9oSnOdDh+sjF lT+E1q3vAWT949naGEECjrMSXrtdssPaUFO1/1bgTJ9+mrhu5j7poxH+GdZOIcCX cHHjrOSj9NK9+q7L7Z3C78TjVFp7UsGfs8c+HNv5eHe8JpJZ+YJl7CqKueDAj4k= =IdMq -----END PGP SIGNATURE----- --Apple-Mail=_91423C09-371B-493C-8133-C8B8A162F8CA-- From nobody Thu Jan 19 09:43:00 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C4D2129458 for ; Thu, 19 Jan 2017 09:42:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 8xpJT4X1N-yd for ; Thu, 19 Jan 2017 09:42:57 -0800 (PST) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 015EE1293F9 for ; Thu, 19 Jan 2017 09:42:56 -0800 (PST) Received: by mail-ua0-x22b.google.com with SMTP id i68so41309943uad.0 for ; Thu, 19 Jan 2017 09:42:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Xi4Ndi0dMGRULNY++1Q3x86u+Mlnd4dNy5LSTZKvDwc=; b=flhqSiZ22y4Oc7DH5xBP9f6dv9LRvcB1PA90gScvBmqEifCXR+2cwqhiS0FMQlYrn1 h54xQgY/gAwO5RZh50fyfkGbN2pMvtGc2Pwpw0Segc9ojdReUWQs0j2Z8ZMaPxyggRSR mGu0vxB1t3+b5ooNt7D1OimpA1YpMvhgu+cc3HqARsI8ORPgqfLZh8eMhbERKivObjYK mDRq1r309C1MRhP8Xaxdeb54C/HLAdWWmINdrE4olgy9h1lA5ZtcNgTjR3FKyGrmrB2J GLxCaPi7+n2+MEFCyDlY7TrwnzKWGKINVZ3s1yHicdwkt9V2pX30Picbv3m2zf6G/2+q 5F2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Xi4Ndi0dMGRULNY++1Q3x86u+Mlnd4dNy5LSTZKvDwc=; b=SWAGk9sduu411r1ufUWGXWAhIkLGe8jE8KH5DvQUlY5j0Dd/BMB8zAOxjX9hUDCtmz Pl8WH3CrTc2SttIWrUv6hi/5H9HlfdiGYuCLV2gAYjA6yGde7lLT29elJlFqeuBRpEHT A4J6o1f6Hv9vpQEXOf8OHqIxTpQi+SnHhwdZs6BCgpJaguvEIu4SaywmJtLfjMCOBcZx G/8oSQK6a14RRvKeQRIkPC1PPBGW+vowyZc+GhHlz23VRqbTb755M0xdpYaq4ce3If1u luWQk7nfDA+kIgqoyW+KcyYgr8B0wnQS39CsuVjhcjXIRECdnhQiry4ZNp8gTS74YwBt O9TQ== X-Gm-Message-State: AIkVDXLYpc5Ho5Z3IjBAfAYOhm2b8UwQYW5T0w3089tdcaxXDLbW5DlwSIASj8RmAIViXpj0Nk5M0jsOMSja83xF X-Received: by 10.159.38.73 with SMTP id 67mr4560729uag.155.1484847775866; Thu, 19 Jan 2017 09:42:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.171.2 with HTTP; Thu, 19 Jan 2017 09:42:34 -0800 (PST) In-Reply-To: <50240d7e06c3427cabaac463a95cdac2@XCH-ALN-003.cisco.com> References: <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <20170117.170305.74705723.sthaug@nethelp.no> <20170119132836.GO1862@angus.ind.wpi.edu> <20170119165247.GV2891@angus.ind.wpi.edu> <50240d7e06c3427cabaac463a95cdac2@XCH-ALN-003.cisco.com> From: Lorenzo Colitti Date: Fri, 20 Jan 2017 02:42:34 +0900 Message-ID: To: "Bernie Volz (volz)" Content-Type: multipart/alternative; boundary=001a114950dc3aa09a054676100a Archived-At: Cc: Fernando Gont , v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 17:42:58 -0000 --001a114950dc3aa09a054676100a Content-Type: text/plain; charset=UTF-8 Bernie, have you read RFC 7934? It lists a number of reasons why it is not recommended for networks to support only DHCPv6 address assignment via IA_NA. I don't think DHCPv6 in itself is a problem. While it does suffer from the limitations I outlined in my earlier message, it is flexible and extensible to way more information than RAs can carry. It's also widely supported. But I really think IA_NA is not appropriate for IPv6 assignment, for the reasons that the authors and the WG outline in RFC7934. Unfortunately, for many, decades of operational familiarity and vendor support with IPv4 networks, where the only way to get an IP address (and only ever ONE address) was DHCP, make it very hard to think of any other address assignment mechanism. SLAAC is regularly dismissed as outlandish and insecure, /64 subnets as wasteful, and the insistence that IPv4 and IPv6 demand different link-addressing practives as religion. "Why can't we just use DHCP", as an earlier message put it. Unfortunately the truth is much more complex than that. If the Internet is eventually to reap the full benefits of IPv6, then we as a technical community and as an industry need to give a chance to a new addressing model where hosts can use as many IPv6 addresses as they need. Right now, that means SLAAC. The fact of the matter is that it SLAAC's security properties are not substantially worse than IA_NA, and anyone who says differently should read RFC 7934 section 9.1, of which I have not yet seen any rebuttal, convincing or otherwise. And as for /64s being wasteful - you saw the earlier messages in this conversation that asserted that prefixes cost money or they are hard to obtain, when in fact the cost is orders of magnitude lower than one cent, and RIR policies ere extremely liberal? It would be extremely easy to simply carry over practices that we have in IPv4 to IPv6. But because applications are incentivized to add application complexity in order to work properly on all networks, there is a risk that we might get stuck there, and never be able to elevate ourselves out of those practices. If that happens will keep suffering the problems caused by IP address scarcity even after scarcity is banished. That would be a bad outcome. Of course I may be wrong and a one-address-per-host model is the right choice. But I don't think we can tell at the moment. Over the years, network administrators that learn about IP (and application developers that write applications) on dual-stack networks with a mix of SLAAC and DHCPv6 will be able to make better choices between these protocols than we can today. Cheers, Lorenzo On Fri, Jan 20, 2017 at 1:59 AM, Bernie Volz (volz) wrote: > While I probably shouldn't send this as it is in the political and not > technical space, I frankly am very disappointed in one company that, while > trying to promote IPv6 usage, has also worked very hard to limit its use by > NOT supporting a protocol developed by the IETF. > > I'm also surprised that organizations haven't pushed harder to get that > company to implement the standards. I suspect though that is because IPv6 > is not yet "critical" for deployment. This provides the company an > opportunity to push their agenda (whatever it may be). > > I will admit that being DHC WG co-chair, coauthor of the some of the > standards, and also a vendor does bias me. > > - Bernie > > --001a114950dc3aa09a054676100a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Bernie,

have you read RFC 79= 34? It lists a number of reasons why it is not recommended for networks to = support only DHCPv6 address assignment via IA_NA.

= I don't think DHCPv6 in itself is a problem. While it does suffer from = the limitations I outlined in my earlier message, it is flexible and extens= ible to way more information than RAs can carry. It's also widely suppo= rted. But I really think IA_NA is not appropriate for IPv6 assignment, for = the reasons that the authors and the WG outline in RFC7934.

<= /div>
Unfortunately, for many, decades of operational familiarity and v= endor support with IPv4 networks, where the only way to get an IP address (= and only ever ONE address) was DHCP, make it very hard to think of any othe= r address assignment mechanism. SLAAC is regularly dismissed as outlandish = and insecure, /64 subnets as wasteful, and the insistence that IPv4 and IPv= 6 demand different link-addressing practives as religion. "Why can'= ;t we just use DHCP", as an earlier message put it. Unfortunately the = truth is much more complex than that.

If the Inter= net is eventually to reap the full benefits of IPv6, then we as a technical= community and as an industry need to give a chance to a new addressing mod= el where hosts can use as many IPv6 addresses as they need. Right now, that= means SLAAC. The fact of the matter is that it SLAAC's security proper= ties are not substantially worse than IA_NA, and anyone who says differentl= y should read RFC 7934 section 9.1, of which I have not yet seen any rebutt= al, convincing or otherwise. And as for /64s being wasteful - you saw the e= arlier messages in this conversation that asserted that prefixes cost money= or they are hard to obtain, when in fact the cost is orders of magnitude l= ower than one cent, and RIR policies ere extremely liberal?

<= /div>
It would be extremely easy to simply carry over practices that we= have in IPv4 to IPv6. But because applications are incentivized to add app= lication complexity in order to work properly on all networks, there is a r= isk that we might get stuck there, and never be able to elevate ourselves o= ut of those practices. If that happens will keep suffering the problems cau= sed by IP address scarcity even after scarcity is banished. That would be a= bad outcome.

Of course I may be wrong and a one-a= ddress-per-host model is the right choice. But I don't think we can tel= l at the moment. Over the years, network administrators that learn about IP= (and application developers that write applications) on dual-stack network= s with a mix of SLAAC and DHCPv6 will be able to make better choices betwee= n these protocols than we can today.

Cheers,
=
Lorenzo

On Fri, Jan 20, 2017 at 1:59 AM, Bernie Volz (volz) <volz@cisco.com> wrote:
While I probably shou= ldn't send this as it is in the political and not technical space, I fr= ankly am very disappointed in one company that, while trying to promote IPv= 6 usage, has also worked very hard to limit its use by NOT supporting a pro= tocol developed by the IETF.

I'm also surprised that organizations haven't pushed harder to get = that company to implement the standards. I suspect though that is because I= Pv6 is not yet "critical" for deployment. This provides the compa= ny an opportunity to push their agenda (whatever it may be).

I will admit that being DHC WG co-chair, coauthor of the some of the standa= rds, and also a vendor does bias me.

- Bernie


--001a114950dc3aa09a054676100a-- From nobody Thu Jan 19 10:36:28 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D92F1294AF for ; Thu, 19 Jan 2017 10:36:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 7LcHtxzIjFM6 for ; Thu, 19 Jan 2017 10:36:25 -0800 (PST) Received: from mail-yb0-x241.google.com (mail-yb0-x241.google.com [IPv6:2607:f8b0:4002:c09::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A57F31293DB for ; Thu, 19 Jan 2017 10:30:45 -0800 (PST) Received: by mail-yb0-x241.google.com with SMTP id 123so3835854ybe.0 for ; Thu, 19 Jan 2017 10:30:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Hkp8j7tmuHhVIMUiWuecujn/nLKOEI5y6yt2IzkX+7w=; b=hlVKTvsYU++fAyAK7Mxli8ZThUyPiFPEzwUwRnvrpo6Y23BGXrPjouKagVk6TrAWgv kIdVXTe63MDNJMvHrx/M4D1kkZsuZ+Nb0YSPgw2y1Mm5M/oMsrvjD/mjGgbBWT/EvPR8 lcgA02ZRKyw+okLsuCp57ubcKrQjTkZ5PRYcevTXtZ/kRsNLddgE0tP8LEU8PXGxsxkc ctza0JzMOO6Yy+F5pUR0HygCcDY0tioSQgAJlALwcbQgm7R76wUqmDElTa1T7ABQHnyY Epwuq43hE2lBSJ2c4Ac8oXFUBYfg1RreSqdtOOAl/jti4YFOMqk93vpH48QrZqh0nn9I NBVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Hkp8j7tmuHhVIMUiWuecujn/nLKOEI5y6yt2IzkX+7w=; b=S63G913lO8p33UWQeTvrjUOwQMbBhte/isy7SsCbu2KZ/EJC+IHMHPHnt2mVf07+Nv CpU+dHGryXUxxaGKY5ol/Ry1v/ZOzaMBP2GTVR7zdZ01D7mW7NYEsb0MAaqzZiVoKL5m ZOjCeAjtGFyWE2sCzT9IADHcebEsmq5a1x91OOK3TC6LA8Mx7MXQiQKw0nu09LhBIlHh RRmFfhERjoAWKPxpYY3e9M+JtJEd2a+IjuigyNsnAWm1UBqf4/f0c9iruBq9AE/UDWuD WLW13nDhtaIHmMkK9zRVgZcpvaFGsIFoi2QHy9XRwYXfvQpZOplkMJ6IVa4es9KrMewa H+7g== X-Gm-Message-State: AIkVDXKrWKrUSXKGLRUHUSTSbFVhPzZzOkKckcTe9rcKpD7bV683z0XcZIjMjhiUon0DKWQoCg0zCZHGDH89LA== X-Received: by 10.200.51.212 with SMTP id d20mr8963405qtb.220.1484850644863; Thu, 19 Jan 2017 10:30:44 -0800 (PST) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.29 with HTTP; Thu, 19 Jan 2017 10:30:44 -0800 (PST) In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F45C2E98BCF@nkgeml514-mbx.china.huawei.com> References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2E981DF@nkgeml514-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2E986B1@nkgeml514-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2E98BCF@nkgeml514-mbx.china.huawei.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Thu, 19 Jan 2017 10:30:44 -0800 X-Google-Sender-Auth: OYjUSHXM-ACMrcnDwuxNaATwiZ0 Message-ID: To: "Liubing (Leo)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IPv6 Ops WG , "v6ops-chairs@tools.ietf.org" Subject: Re: [v6ops] Possible consensus of dhcpv6-slaac-problem draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 18:36:26 -0000 At Thu, 19 Jan 2017 02:50:21 +0000, "Liubing (Leo)" wrote: > > If I were the author, I'd step back and focus on one obviously "important" > > point: coexistence of SLAAC and address assignment by > > DHCPv6 isn't possible in some cases, and very carefully add other points if > > and when we have a greater consensus that they are operationally > > important. But perhaps you'd rather be "comprehensive" > > and don't like the idea - in that case, I think we just have to agree to > > disagree. > > [Bing] Thanks for this constructive suggestion. I think the ambiguity analysis needs to be "comprehensive"; but not necessarily the operational divergence. > As Brian suggested in another thread, do you think it may help the > draft more readable if we separate the operational divergence into > "Major" and "Minor"? Also to respond to Brian's suggestion: the short answer is "no", but I think I should explain it in a bit more detail. I don't mind including "minor" issues per se, and I don't see the need for separation. After all what's important/not important or what's major/minor is subjective, so it would be inevitable to have points that are minor to some people. Using the word "major" and "minor", my main concern with the current version of the draft is that it spends a quite lot of text for "too minor" issues that the entire discussions make a distraction (see, for example, the comment on Section 3 item 4 of my previous review: https://www.ietf.org/mail-archive/web/v6ops/current/msg24444.html). So my point is rather "excluding 'too minor' points" than clarifying which is major and which is minor. I can live with including relatively minor issues itself, and it's okay to not mark them "minor" as long as we have the courage of dropping too minor points with the energy spent for them. -- JINMEI, Tatuya From nobody Thu Jan 19 10:39:46 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31A021294C2 for ; Thu, 19 Jan 2017 10:39:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 RP8eCjCQE6vb for ; Thu, 19 Jan 2017 10:39:43 -0800 (PST) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF57E129481 for ; Thu, 19 Jan 2017 10:39:43 -0800 (PST) Received: by mail-pg0-x234.google.com with SMTP id 194so16173010pgd.2 for ; Thu, 19 Jan 2017 10:39:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:message-id:mime-version:subject:date:references:to:in-reply-to; bh=Qh7pvbAgU6lvSuEm06KqxXY2xJyytWvp8Nm3TpISbTU=; b=K+bNSx9sRVBXwS2vPErTQH3/UXn4zVSnCPUk6QcsPQ5bbCjG4G6FxEWaiGRcmMR4u6 i9+pLmZsgi3bOVYb1RmvC6rgs2Z2T7sHe2JFeSz9ix4zJDxyRIcIQG+VJymaom2u4dJv UTq7ssGXezMmMUd5WWRlQokmr5j8twhFpeCIYxAAoztPPGI5tgOpeWkFKxCuZ9+vm3HV bgQJuvDudm9BVnYL+nlxlsVPHu0N9vuhMo8KR81JCf1a8LgKnRUXYI8TCH7nmZ1gXy5T 8K7+Xs1n6q04CJs/nwkTKq1cF49lY21L4muQz7j1TJsjgqUfOH9UiUg0YGOHKPbnPNTm OVVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :references:to:in-reply-to; bh=Qh7pvbAgU6lvSuEm06KqxXY2xJyytWvp8Nm3TpISbTU=; b=PlhGjIKk1piYuVcxjrDxurpeqgvVK7KldKzmoXuI69L9Iq/UjHGgbmtvCfbmaSrT9i lSLJL/bkoZRJcNTdj11aGCHkWvPG46r0IgbKIfByrCGRcFrLfBTdBlmgJofkXc6KjcAw dM05MHlWXDUnS4HMqVDtN6PjLouvGR9MFQMVBbuvcIHupmT162cICBLVeqePkf9zQa4p WUuPx9V2/2ZvIHR1NNaNgJofOt1K7pStIDASUYEQyL9+ORAb8/QFnPVnsI5mDPSh/szV cYCZ9JNcMArRH98agQcFa5q4OxpomvWzwjypTYwFAtJCbvncTIhknURNSrj8gJkBVMRA CDWg== X-Gm-Message-State: AIkVDXLwUFFvEuhAGbEqzOKMRzacRMLHafcfTbObXCioZfsQOcSnezmO5tgZL0bw3mkANCKq X-Received: by 10.99.226.3 with SMTP id q3mr12050307pgh.37.1484851182767; Thu, 19 Jan 2017 10:39:42 -0800 (PST) Received: from ?IPv6:2620::10e7:10:f014:f740:3be3:e231? ([2620:0:10e7:10:f014:f740:3be3:e231]) by smtp.gmail.com with ESMTPSA id a24sm10617420pfh.33.2017.01.19.10.39.41 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 19 Jan 2017 10:39:41 -0800 (PST) From: james woodyatt Content-Type: multipart/alternative; boundary="Apple-Mail=_58D8C1C8-32EF-4F70-A50A-332C5DE7108F" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Date: Thu, 19 Jan 2017 10:39:41 -0800 References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <99204933-5CB6-4E89-BD6A-FD40136DF6F5@steffann.nl> To: IPv6 Ops WG In-Reply-To: X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 18:39:45 -0000 --Apple-Mail=_58D8C1C8-32EF-4F70-A50A-332C5DE7108F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jan 19, 2017, at 01:50, Sander Steffann wrote: > On Jan 17, 2017, at 15:51, Mark Smith wrote: >>=20 >> Implementing every option every where to try to provide everybody = with their favorite method ("provide all options in both RA and DHCPv6") = just creates complexity, confusion, more code to write and more things = that can break. >=20 > That's a valid concern. I suggested using the same options for both RA = and DHCPv6 exactly for this reason: to keep things simpler. With the = current direction things seem to be moving to I'm afraid we're going to = end up with different options for DNS, NTP, default gateway etc in both = protocols, and that would be really bad. [=E2=80=A6] Wait=E2=80=A6 what? If there is a movement to load more options into RA Messages than those = necessary for providing hosts with DNS configuration even when they = don=E2=80=99t implement stateful DHCPv6, then I=E2=80=99d like to have = words with its leaders. There is no reasonable need for additional = service location information pushed in RA Messages beyond the DNS = servers and name search parameters because we have DNS-SD for providing = network parameters to hosts in general. DHCP may still be necessary for = providing some network operators with fine-grained centralized leasing = of network parameter configurations of individual specific hosts, but RA = Messages are more broadly required on most popular link layers, and they = should remain much much simpler to process. I see that I-D.v6ops-dhcpv6-slaac-problem doesn=E2=80=99t seem confused = about this point, so how did we arrive at this point in the discussion? --james woodyatt > --Apple-Mail=_58D8C1C8-32EF-4F70-A50A-332C5DE7108F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Jan 19, 2017, at 01:50, Sander Steffann = <sander@steffann.nl> wrote:
On Jan 17, 2017, at 15:51, Mark Smith <markzzzsmith@gmail.com> wrote:

Implementing = every option every where to try to provide everybody with their favorite = method ("provide all = options in both RA and DHCPv6") just creates = complexity, confusion, more code to write and more things that can = break.

That's a valid concern. I suggested using the same options = for both RA and DHCPv6 exactly for this reason: to keep things simpler. = With the current direction things seem to be moving to I'm afraid we're = going to end up with different options for DNS, NTP, default gateway etc = in both protocols, and that would be really bad. = [=E2=80=A6]

Wait=E2=80=A6 what?

If there is a movement to load more = options into RA Messages than those necessary for providing hosts with = DNS configuration even when they don=E2=80=99t implement stateful = DHCPv6, then I=E2=80=99d like to have words with its leaders. There is = no reasonable need for additional service location information pushed in = RA Messages beyond the DNS servers and name search parameters because we = have DNS-SD for providing network parameters to hosts in general. DHCP = may still be necessary for providing some network operators with = fine-grained centralized leasing of network parameter configurations of = individual specific hosts, but RA Messages are more broadly required on = most popular link layers, and they should remain much much simpler to = process.

I see = that I-D.v6ops-dhcpv6-slaac-problem doesn=E2=80=99t seem confused about = this point, so how did we arrive at this point in the = discussion?


--james woodyatt <jhw@google.com>



= --Apple-Mail=_58D8C1C8-32EF-4F70-A50A-332C5DE7108F-- From nobody Thu Jan 19 11:00:39 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02CA41294AC for ; Thu, 19 Jan 2017 11:00:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 SPN0mEWcLf_t for ; Thu, 19 Jan 2017 11:00:36 -0800 (PST) Received: from mail-yb0-x22e.google.com (mail-yb0-x22e.google.com [IPv6:2607:f8b0:4002:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A69F4129407 for ; Thu, 19 Jan 2017 11:00:36 -0800 (PST) Received: by mail-yb0-x22e.google.com with SMTP id j82so31449350ybg.1 for ; Thu, 19 Jan 2017 11:00:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zb6UtNQjIkQaoReZNDCrzBcEPOatsytbuSvXuS4H0zY=; b=dXTJQGGSOabR6n39jOS8wGnXM2o5U/1kasH/+J6SobiwbKKLTkbEwYJPAZeas4bxKN JT9/B/MYmakZpylRPCHIBa/GMh/YLXF2vJFwXne2VYd2f+ZRDEG4CZ4KTTuAMecLXXHz N7iOcvz4Zsvb5QDjhemAPTJH6gGsiTnDSOSRPByiHwGtZPSsqwgkaibELSE5zcR8RYQn z+qcCtu3OXt7JmmZTg1jllYZ7BSvUrvSLl+4t7+qCXQCTgyBWxegRJWaq0EYN7VdxMBg W7MWKIxPcxXEKo/gLB3Z5Jb3gto81/Y2wak0Ec3DxgRBx+CcTIROiqIazJDGT60s3la1 IETQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zb6UtNQjIkQaoReZNDCrzBcEPOatsytbuSvXuS4H0zY=; b=heSosqIhEFnEpQRxO3JF0JVWR4uAPtRKEysuG2GG9owvxrDClWFA/ZLfA42Ss710Ks JXFvzrrbrdzI+A5/8MRNzPrLwp+lF66GZMcV5Y22j22OdqVv7l5xruX6Cv5JJNyJSRNi d1XTfcEXQXqHOK0PtJulpJPi93h1KGRZV7pNRsSN1QApx3PqNNSRNL1PJqnCIx5flpi0 JEGVXKnsjsreGRz0Fy6cUSFPm4EBQR6nI/eOqtIHsfglDTRJr/Ofp5T1jVEeBZqeO3Lb j/1VKuCnOSOUtffj1xbP+AXCOG+h4Zr4CIGuKZLFS/ufp1l+pXsxtFqDVdTymPViizFB 3QVw== X-Gm-Message-State: AIkVDXJhiS/xVod+ljen3RobZ9R3UR3azsyX3lZvIhAWiBuYW4S07jNlQuC8VyBfrKMIIg== X-Received: by 10.55.47.69 with SMTP id v66mr9221338qkh.222.1484852435412; Thu, 19 Jan 2017 11:00:35 -0800 (PST) Received: from [192.168.1.228] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id 140sm3816084qkj.19.2017.01.19.11.00.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Jan 2017 11:00:34 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ted Lemon In-Reply-To: Date: Thu, 19 Jan 2017 14:00:33 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <99204933-5CB6-4E89-BD6A-FD40136DF6F5@steffann.nl> To: james woodyatt X-Mailer: Apple Mail (2.3259) Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 19:00:38 -0000 As one of the authors of RFC 3315, I feel I should chime in here to = mention some discussion that has transpired since 3315 and related = documents were published, which I think has bearing on the question of = whether to stuff more options into RAs. To understand this, it is important to grasp the distinction between = information that relates to the local network to which a host has = connected, and information that relates to the host, independent of = where it may connect. In DHCPv4, many options fall into the latter = category. Some DHCPv6 options (e.g., the NTP servers option) do as = well. It is a really bad idea for the host to trust the local network to = configure things like this. Do you really want the local Starbucks to = provide you with your source of time? Consequently, DHCP, which is = really an infrastructure protocol, is a poor choice for configuring such = parameters. Stuffing those parameters into ND would be compounding the = mistake. Please do not do this. From nobody Thu Jan 19 11:44:12 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABC97129463 for ; Thu, 19 Jan 2017 11:44:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 9u0q2tqbuVsW for ; Thu, 19 Jan 2017 11:44:10 -0800 (PST) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D12C12943E for ; Thu, 19 Jan 2017 11:44:10 -0800 (PST) Received: by mail-ua0-x235.google.com with SMTP id y9so44824424uae.2 for ; Thu, 19 Jan 2017 11:44:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=eOodWs+++k+byWCl6Y4T1MifOoR1pQVbkubEL+QXRqQ=; b=Tm0b0gUyU8fsugy0KkcokDnZyfzXn/Kt8K02aptyCP9OP/PnnB2HOQ8y6wRh/b17Pu h9jWTtM2He1SKMXRvbNJcrQ4GmssN/p9L+qO4FlM55T1aNkBJjV6zf8Mf4FQaUVxEUSv 1YicPXQDvro+n0KCV/xx/ybopTqJoIhC3GHBVLOnr/pBvKQw35aSZLYl8bYLEfqJmQfY EeI8LklwYHC7Z1Eamfi9aO/icUXankuiTE00KlKFAvNAvFuWyhMZKH7nnVY40Ly0o7qj XaxZwB2oVfeBVYbTi6LWsQ/D5Ejwri7NheOfhVDbt1EQgqZ53L5UIki30zn68+Jm8TL4 +TsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=eOodWs+++k+byWCl6Y4T1MifOoR1pQVbkubEL+QXRqQ=; b=VBVLCsLyqvtBGeCZoevQGT72pNztpTxpIIokzhUUjNkLhM1mrsPV7E9z0COTj4IQA7 MbB4/wNmkKPwDoVhCWY0IMfbbFBF3AAooPWoGlTxhoOgEOMmMWLraQU1gOufr1zmiazP 0AFeh4kZj+bKl9WK9LyJfTjLrg9Gx/x1YHCB1ReNxI/eg1tyXZdMt/3siBTACNwt1vcQ Gqck+6SgX1U/7lBrzDYOBA5CFrs6DeOTpXLoUpn3qS9tQe0bYCrRs1n0xXwYFiYixH35 nwaKb+X4VvGeL6ZLr2+LoTZ/2nW/QH7gc7JQ28ZrazMM9ms3xa98dFDtu0NotFqzZGM4 v9XA== X-Gm-Message-State: AIkVDXLLB9mWGiQzLnoWldYDYCwklD04gTUb+wDaxFrQZB1apXmtl2Cd0x9y+BZG+pwgTaBjIkM/7I6zUx0+uw== X-Received: by 10.176.65.198 with SMTP id 64mr5605966uap.40.1484855049449; Thu, 19 Jan 2017 11:44:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.2.235 with HTTP; Thu, 19 Jan 2017 11:43:38 -0800 (PST) In-Reply-To: References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <99204933-5CB6-4E89-BD6A-FD40136DF6F5@steffann.nl> From: Mark Smith Date: Fri, 20 Jan 2017 06:43:38 +1100 Message-ID: To: james woodyatt Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 19:44:11 -0000 On 20 January 2017 at 05:39, james woodyatt wrote: > On Jan 19, 2017, at 01:50, Sander Steffann wrote: > > On Jan 17, 2017, at 15:51, Mark Smith wrote: > > > Implementing every option every where to try to provide everybody with th= eir > favorite method ("provide all options in both RA and DHCPv6") just create= s > complexity, confusion, more code to write and more things that can break. > > > That's a valid concern. I suggested using the same options for both RA an= d > DHCPv6 exactly for this reason: to keep things simpler. With the current > direction things seem to be moving to I'm afraid we're going to end up wi= th > different options for DNS, NTP, default gateway etc in both protocols, an= d > that would be really bad. [=E2=80=A6] > > > Wait=E2=80=A6 what? > > If there is a movement to load more options into RA Messages than those > necessary for providing hosts with DNS configuration even when they don= =E2=80=99t > implement stateful DHCPv6, then I=E2=80=99d like to have words with its l= eaders. > There is no reasonable need for additional service location information > pushed in RA Messages beyond the DNS servers and name search parameters > because we have DNS-SD for providing network parameters to hosts in gener= al. > DHCP may still be necessary for providing some network operators with > fine-grained centralized leasing of network parameter configurations of > individual specific hosts, but RA Messages are more broadly required on m= ost > popular link layers, and they should remain much much simpler to process. > > I see that I-D.v6ops-dhcpv6-slaac-problem doesn=E2=80=99t seem confused a= bout this > point, so how did we arrive at this point in the discussion? > I think it is because I said that: - RDNSS options were justified by saying low end embedded devices were too resource constrained to run a (stateless) DHCPv6 client (that doesn't seem to be in the RFC, however I'm pretty sure that was the only argument I accepted personally for them at the time) - I've since changed my mind because CPU and memory is always getting cheaper, stateless DHCPv6 is quite simple, and we now we have confusion about whether to deploy RDNSS or stateless DHCPv6, and issues about universal RDNSS support, which was something I thought was likely to occur, unless the use case for RDNSS was very clear. Brian has said RDNSS was aimed less resource constrained environments such as cafes, homes etc. Unfortunately that doesn't seem to be that clear, as much larger organisations are seeming to see it as the general purpose way of deploying DNS parameters (and re-architecthing their network when some of their equipment doesn't support it - L2VPNs just to make RDNSS work? =C2=A1Ay, caramba!) "IPv6-only at Microsoft" https://blog.apnic.net/2017/01/19/ipv6-only-at-microsoft/ Regards, Mark. From nobody Thu Jan 19 11:57:23 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4140C1293D9 for ; Thu, 19 Jan 2017 11:57:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 WNjuA06NPWFr for ; Thu, 19 Jan 2017 11:57:19 -0800 (PST) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CB5F120725 for ; Thu, 19 Jan 2017 11:57:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v0JJvIj9021302; Thu, 19 Jan 2017 12:57:18 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (xch15-06-08.nw.nos.boeing.com [137.136.238.222]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v0JJvBEQ021249 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Thu, 19 Jan 2017 12:57:11 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 19 Jan 2017 11:57:10 -0800 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1178.000; Thu, 19 Jan 2017 11:57:10 -0800 From: "Templin, Fred L" To: Lorenzo Colitti , "Bernie Volz (volz)" Thread-Topic: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem Thread-Index: AQHScnt/mcZFQAgpf0q2WHUDZOjC4aFANw3Q Date: Thu, 19 Jan 2017 19:57:10 +0000 Message-ID: <60c76dc336c34899955a204cb336b5e2@XCH15-06-08.nw.nos.boeing.com> References: <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <20170117.170305.74705723.sthaug@nethelp.no> <20170119132836.GO1862@angus.ind.wpi.edu> <20170119165247.GV2891@angus.ind.wpi.edu> <50240d7e06c3427cabaac463a95cdac2@XCH-ALN-003.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: multipart/alternative; boundary="_000_60c76dc336c34899955a204cb336b5e2XCH150608nwnosboeingcom_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: Fernando Gont , v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 19:57:21 -0000 --_000_60c76dc336c34899955a204cb336b5e2XCH150608nwnosboeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIHdlIHVzZSBESENQdjYgSUFfUEQgb24gQW5kcm9pZCBhbGwgdGhlIHRpbWUuIEl0IHdvcmtz IGdyZWF0LCBhbmQgb25seSByZXF1aXJlcw0KYSBjb3VwbGUgb2YgbWVzc2FnZXMgb24gdGhlIGNs aWVudCBzaWRlLg0KDQpUaGFua3MgLSBGcmVkDQoNCkZyb206IHY2b3BzIFttYWlsdG86djZvcHMt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIExvcmVuem8gQ29saXR0aQ0KU2VudDogVGh1 cnNkYXksIEphbnVhcnkgMTksIDIwMTcgOTo0MyBBTQ0KVG86IEJlcm5pZSBWb2x6ICh2b2x6KSA8 dm9sekBjaXNjby5jb20+DQpDYzogRmVybmFuZG8gR29udCA8ZmdvbnRAc2k2bmV0d29ya3MuY29t PjsgdjZvcHMgbGlzdCA8djZvcHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBkcmFm dC1pZXRmLXY2b3BzLWRoY3B2Ni1zbGFhYy1wcm9ibGVtDQoNCkJlcm5pZSwNCg0KaGF2ZSB5b3Ug cmVhZCBSRkMgNzkzND8gSXQgbGlzdHMgYSBudW1iZXIgb2YgcmVhc29ucyB3aHkgaXQgaXMgbm90 IHJlY29tbWVuZGVkIGZvciBuZXR3b3JrcyB0byBzdXBwb3J0IG9ubHkgREhDUHY2IGFkZHJlc3Mg YXNzaWdubWVudCB2aWEgSUFfTkEuDQoNCkkgZG9uJ3QgdGhpbmsgREhDUHY2IGluIGl0c2VsZiBp cyBhIHByb2JsZW0uIFdoaWxlIGl0IGRvZXMgc3VmZmVyIGZyb20gdGhlIGxpbWl0YXRpb25zIEkg b3V0bGluZWQgaW4gbXkgZWFybGllciBtZXNzYWdlLCBpdCBpcyBmbGV4aWJsZSBhbmQgZXh0ZW5z aWJsZSB0byB3YXkgbW9yZSBpbmZvcm1hdGlvbiB0aGFuIFJBcyBjYW4gY2FycnkuIEl0J3MgYWxz byB3aWRlbHkgc3VwcG9ydGVkLiBCdXQgSSByZWFsbHkgdGhpbmsgSUFfTkEgaXMgbm90IGFwcHJv cHJpYXRlIGZvciBJUHY2IGFzc2lnbm1lbnQsIGZvciB0aGUgcmVhc29ucyB0aGF0IHRoZSBhdXRo b3JzIGFuZCB0aGUgV0cgb3V0bGluZSBpbiBSRkM3OTM0Lg0KDQpVbmZvcnR1bmF0ZWx5LCBmb3Ig bWFueSwgZGVjYWRlcyBvZiBvcGVyYXRpb25hbCBmYW1pbGlhcml0eSBhbmQgdmVuZG9yIHN1cHBv cnQgd2l0aCBJUHY0IG5ldHdvcmtzLCB3aGVyZSB0aGUgb25seSB3YXkgdG8gZ2V0IGFuIElQIGFk ZHJlc3MgKGFuZCBvbmx5IGV2ZXIgT05FIGFkZHJlc3MpIHdhcyBESENQLCBtYWtlIGl0IHZlcnkg aGFyZCB0byB0aGluayBvZiBhbnkgb3RoZXIgYWRkcmVzcyBhc3NpZ25tZW50IG1lY2hhbmlzbS4g U0xBQUMgaXMgcmVndWxhcmx5IGRpc21pc3NlZCBhcyBvdXRsYW5kaXNoIGFuZCBpbnNlY3VyZSwg LzY0IHN1Ym5ldHMgYXMgd2FzdGVmdWwsIGFuZCB0aGUgaW5zaXN0ZW5jZSB0aGF0IElQdjQgYW5k IElQdjYgZGVtYW5kIGRpZmZlcmVudCBsaW5rLWFkZHJlc3NpbmcgcHJhY3RpdmVzIGFzIHJlbGln aW9uLiAiV2h5IGNhbid0IHdlIGp1c3QgdXNlIERIQ1AiLCBhcyBhbiBlYXJsaWVyIG1lc3NhZ2Ug cHV0IGl0LiBVbmZvcnR1bmF0ZWx5IHRoZSB0cnV0aCBpcyBtdWNoIG1vcmUgY29tcGxleCB0aGFu IHRoYXQuDQoNCklmIHRoZSBJbnRlcm5ldCBpcyBldmVudHVhbGx5IHRvIHJlYXAgdGhlIGZ1bGwg YmVuZWZpdHMgb2YgSVB2NiwgdGhlbiB3ZSBhcyBhIHRlY2huaWNhbCBjb21tdW5pdHkgYW5kIGFz IGFuIGluZHVzdHJ5IG5lZWQgdG8gZ2l2ZSBhIGNoYW5jZSB0byBhIG5ldyBhZGRyZXNzaW5nIG1v ZGVsIHdoZXJlIGhvc3RzIGNhbiB1c2UgYXMgbWFueSBJUHY2IGFkZHJlc3NlcyBhcyB0aGV5IG5l ZWQuIFJpZ2h0IG5vdywgdGhhdCBtZWFucyBTTEFBQy4gVGhlIGZhY3Qgb2YgdGhlIG1hdHRlciBp cyB0aGF0IGl0IFNMQUFDJ3Mgc2VjdXJpdHkgcHJvcGVydGllcyBhcmUgbm90IHN1YnN0YW50aWFs bHkgd29yc2UgdGhhbiBJQV9OQSwgYW5kIGFueW9uZSB3aG8gc2F5cyBkaWZmZXJlbnRseSBzaG91 bGQgcmVhZCBSRkMgNzkzNCBzZWN0aW9uIDkuMSwgb2Ygd2hpY2ggSSBoYXZlIG5vdCB5ZXQgc2Vl biBhbnkgcmVidXR0YWwsIGNvbnZpbmNpbmcgb3Igb3RoZXJ3aXNlLiBBbmQgYXMgZm9yIC82NHMg YmVpbmcgd2FzdGVmdWwgLSB5b3Ugc2F3IHRoZSBlYXJsaWVyIG1lc3NhZ2VzIGluIHRoaXMgY29u dmVyc2F0aW9uIHRoYXQgYXNzZXJ0ZWQgdGhhdCBwcmVmaXhlcyBjb3N0IG1vbmV5IG9yIHRoZXkg YXJlIGhhcmQgdG8gb2J0YWluLCB3aGVuIGluIGZhY3QgdGhlIGNvc3QgaXMgb3JkZXJzIG9mIG1h Z25pdHVkZSBsb3dlciB0aGFuIG9uZSBjZW50LCBhbmQgUklSIHBvbGljaWVzIGVyZSBleHRyZW1l bHkgbGliZXJhbD8NCg0KSXQgd291bGQgYmUgZXh0cmVtZWx5IGVhc3kgdG8gc2ltcGx5IGNhcnJ5 IG92ZXIgcHJhY3RpY2VzIHRoYXQgd2UgaGF2ZSBpbiBJUHY0IHRvIElQdjYuIEJ1dCBiZWNhdXNl IGFwcGxpY2F0aW9ucyBhcmUgaW5jZW50aXZpemVkIHRvIGFkZCBhcHBsaWNhdGlvbiBjb21wbGV4 aXR5IGluIG9yZGVyIHRvIHdvcmsgcHJvcGVybHkgb24gYWxsIG5ldHdvcmtzLCB0aGVyZSBpcyBh IHJpc2sgdGhhdCB3ZSBtaWdodCBnZXQgc3R1Y2sgdGhlcmUsIGFuZCBuZXZlciBiZSBhYmxlIHRv IGVsZXZhdGUgb3Vyc2VsdmVzIG91dCBvZiB0aG9zZSBwcmFjdGljZXMuIElmIHRoYXQgaGFwcGVu cyB3aWxsIGtlZXAgc3VmZmVyaW5nIHRoZSBwcm9ibGVtcyBjYXVzZWQgYnkgSVAgYWRkcmVzcyBz Y2FyY2l0eSBldmVuIGFmdGVyIHNjYXJjaXR5IGlzIGJhbmlzaGVkLiBUaGF0IHdvdWxkIGJlIGEg YmFkIG91dGNvbWUuDQoNCk9mIGNvdXJzZSBJIG1heSBiZSB3cm9uZyBhbmQgYSBvbmUtYWRkcmVz cy1wZXItaG9zdCBtb2RlbCBpcyB0aGUgcmlnaHQgY2hvaWNlLiBCdXQgSSBkb24ndCB0aGluayB3 ZSBjYW4gdGVsbCBhdCB0aGUgbW9tZW50LiBPdmVyIHRoZSB5ZWFycywgbmV0d29yayBhZG1pbmlz dHJhdG9ycyB0aGF0IGxlYXJuIGFib3V0IElQIChhbmQgYXBwbGljYXRpb24gZGV2ZWxvcGVycyB0 aGF0IHdyaXRlIGFwcGxpY2F0aW9ucykgb24gZHVhbC1zdGFjayBuZXR3b3JrcyB3aXRoIGEgbWl4 IG9mIFNMQUFDIGFuZCBESENQdjYgd2lsbCBiZSBhYmxlIHRvIG1ha2UgYmV0dGVyIGNob2ljZXMg YmV0d2VlbiB0aGVzZSBwcm90b2NvbHMgdGhhbiB3ZSBjYW4gdG9kYXkuDQoNCkNoZWVycywNCkxv cmVuem8NCg0KT24gRnJpLCBKYW4gMjAsIDIwMTcgYXQgMTo1OSBBTSwgQmVybmllIFZvbHogKHZv bHopIDx2b2x6QGNpc2NvLmNvbTxtYWlsdG86dm9sekBjaXNjby5jb20+PiB3cm90ZToNCldoaWxl IEkgcHJvYmFibHkgc2hvdWxkbid0IHNlbmQgdGhpcyBhcyBpdCBpcyBpbiB0aGUgcG9saXRpY2Fs IGFuZCBub3QgdGVjaG5pY2FsIHNwYWNlLCBJIGZyYW5rbHkgYW0gdmVyeSBkaXNhcHBvaW50ZWQg aW4gb25lIGNvbXBhbnkgdGhhdCwgd2hpbGUgdHJ5aW5nIHRvIHByb21vdGUgSVB2NiB1c2FnZSwg aGFzIGFsc28gd29ya2VkIHZlcnkgaGFyZCB0byBsaW1pdCBpdHMgdXNlIGJ5IE5PVCBzdXBwb3J0 aW5nIGEgcHJvdG9jb2wgZGV2ZWxvcGVkIGJ5IHRoZSBJRVRGLg0KDQpJJ20gYWxzbyBzdXJwcmlz ZWQgdGhhdCBvcmdhbml6YXRpb25zIGhhdmVuJ3QgcHVzaGVkIGhhcmRlciB0byBnZXQgdGhhdCBj b21wYW55IHRvIGltcGxlbWVudCB0aGUgc3RhbmRhcmRzLiBJIHN1c3BlY3QgdGhvdWdoIHRoYXQg aXMgYmVjYXVzZSBJUHY2IGlzIG5vdCB5ZXQgImNyaXRpY2FsIiBmb3IgZGVwbG95bWVudC4gVGhp cyBwcm92aWRlcyB0aGUgY29tcGFueSBhbiBvcHBvcnR1bml0eSB0byBwdXNoIHRoZWlyIGFnZW5k YSAod2hhdGV2ZXIgaXQgbWF5IGJlKS4NCg0KSSB3aWxsIGFkbWl0IHRoYXQgYmVpbmcgREhDIFdH IGNvLWNoYWlyLCBjb2F1dGhvciBvZiB0aGUgc29tZSBvZiB0aGUgc3RhbmRhcmRzLCBhbmQgYWxz byBhIHZlbmRvciBkb2VzIGJpYXMgbWUuDQoNCi0gQmVybmllDQoNCg== --_000_60c76dc336c34899955a204cb336b5e2XCH150608nwnosboeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLmhvZW56Yg0KCXttc28t c3R5bGUtbmFtZTpob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s b3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGlu O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5IaSwgd2UgdXNlIERIQ1B2NiBJQV9QRCBvbiBBbmRyb2lkIGFsbCB0aGUg dGltZS4gSXQgd29ya3MgZ3JlYXQsIGFuZCBvbmx5IHJlcXVpcmVzPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PmEgY291cGxlIG9mIG1lc3NhZ2VzIG9uIHRoZSBjbGllbnQgc2lkZS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyAtIEZyZWQ8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEg MS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiB2Nm9w cyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkxv cmVuem8gQ29saXR0aTxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgSmFudWFyeSAxOSwgMjAx NyA5OjQzIEFNPGJyPg0KPGI+VG86PC9iPiBCZXJuaWUgVm9seiAodm9seikgJmx0O3ZvbHpAY2lz Y28uY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gRmVybmFuZG8gR29udCAmbHQ7ZmdvbnRAc2k2bmV0 d29ya3MuY29tJmd0OzsgdjZvcHMgbGlzdCAmbHQ7djZvcHNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbdjZvcHNdIGRyYWZ0LWlldGYtdjZvcHMtZGhjcHY2LXNsYWFjLXBy b2JsZW08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkJlcm5pZSw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+aGF2ZSB5b3UgcmVhZCBSRkMgNzkzND8gSXQgbGlzdHMgYSBudW1iZXIg b2YgcmVhc29ucyB3aHkgaXQgaXMgbm90IHJlY29tbWVuZGVkIGZvciBuZXR3b3JrcyB0byBzdXBw b3J0IG9ubHkgREhDUHY2IGFkZHJlc3MgYXNzaWdubWVudCB2aWEgSUFfTkEuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZG9uJ3QgdGhpbmsg REhDUHY2IGluIGl0c2VsZiBpcyBhIHByb2JsZW0uIFdoaWxlIGl0IGRvZXMgc3VmZmVyIGZyb20g dGhlIGxpbWl0YXRpb25zIEkgb3V0bGluZWQgaW4gbXkgZWFybGllciBtZXNzYWdlLCBpdCBpcyBm bGV4aWJsZSBhbmQgZXh0ZW5zaWJsZSB0byB3YXkgbW9yZSBpbmZvcm1hdGlvbiB0aGFuIFJBcyBj YW4gY2FycnkuIEl0J3MgYWxzbyB3aWRlbHkgc3VwcG9ydGVkLiBCdXQgSSByZWFsbHkNCiB0aGlu ayBJQV9OQSBpcyBub3QgYXBwcm9wcmlhdGUgZm9yIElQdjYgYXNzaWdubWVudCwgZm9yIHRoZSBy ZWFzb25zIHRoYXQgdGhlIGF1dGhvcnMgYW5kIHRoZSBXRyBvdXRsaW5lIGluIFJGQzc5MzQuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlVuZm9y dHVuYXRlbHksIGZvciBtYW55LCBkZWNhZGVzIG9mIG9wZXJhdGlvbmFsIGZhbWlsaWFyaXR5IGFu ZCB2ZW5kb3Igc3VwcG9ydCB3aXRoIElQdjQgbmV0d29ya3MsIHdoZXJlIHRoZSBvbmx5IHdheSB0 byBnZXQgYW4gSVAgYWRkcmVzcyAoYW5kIG9ubHkgZXZlciBPTkUgYWRkcmVzcykgd2FzIERIQ1As IG1ha2UgaXQgdmVyeSBoYXJkIHRvIHRoaW5rIG9mIGFueSBvdGhlciBhZGRyZXNzIGFzc2lnbm1l bnQNCiBtZWNoYW5pc20uIFNMQUFDIGlzIHJlZ3VsYXJseSBkaXNtaXNzZWQgYXMgb3V0bGFuZGlz aCBhbmQgaW5zZWN1cmUsIC82NCBzdWJuZXRzIGFzIHdhc3RlZnVsLCBhbmQgdGhlIGluc2lzdGVu Y2UgdGhhdCBJUHY0IGFuZCBJUHY2IGRlbWFuZCBkaWZmZXJlbnQgbGluay1hZGRyZXNzaW5nIHBy YWN0aXZlcyBhcyByZWxpZ2lvbi4gJnF1b3Q7V2h5IGNhbid0IHdlIGp1c3QgdXNlIERIQ1AmcXVv dDssIGFzIGFuIGVhcmxpZXIgbWVzc2FnZSBwdXQgaXQuIFVuZm9ydHVuYXRlbHkNCiB0aGUgdHJ1 dGggaXMgbXVjaCBtb3JlIGNvbXBsZXggdGhhbiB0aGF0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB0aGUgSW50ZXJuZXQgaXMgZXZlbnR1 YWxseSB0byByZWFwIHRoZSBmdWxsIGJlbmVmaXRzIG9mIElQdjYsIHRoZW4gd2UgYXMgYSB0ZWNo bmljYWwgY29tbXVuaXR5IGFuZCBhcyBhbiBpbmR1c3RyeSBuZWVkIHRvIGdpdmUgYSBjaGFuY2Ug dG8gYSBuZXcgYWRkcmVzc2luZyBtb2RlbCB3aGVyZSBob3N0cyBjYW4gdXNlIGFzIG1hbnkgSVB2 NiBhZGRyZXNzZXMgYXMgdGhleSBuZWVkLiBSaWdodCBub3csIHRoYXQNCiBtZWFucyBTTEFBQy4g VGhlIGZhY3Qgb2YgdGhlIG1hdHRlciBpcyB0aGF0IGl0IFNMQUFDJ3Mgc2VjdXJpdHkgcHJvcGVy dGllcyBhcmUgbm90IHN1YnN0YW50aWFsbHkgd29yc2UgdGhhbiBJQV9OQSwgYW5kIGFueW9uZSB3 aG8gc2F5cyBkaWZmZXJlbnRseSBzaG91bGQgcmVhZCBSRkMgNzkzNCBzZWN0aW9uIDkuMSwgb2Yg d2hpY2ggSSBoYXZlIG5vdCB5ZXQgc2VlbiBhbnkgcmVidXR0YWwsIGNvbnZpbmNpbmcgb3Igb3Ro ZXJ3aXNlLiBBbmQgYXMNCiBmb3IgLzY0cyBiZWluZyB3YXN0ZWZ1bCAtIHlvdSBzYXcgdGhlIGVh cmxpZXIgbWVzc2FnZXMgaW4gdGhpcyBjb252ZXJzYXRpb24gdGhhdCBhc3NlcnRlZCB0aGF0IHBy ZWZpeGVzIGNvc3QgbW9uZXkgb3IgdGhleSBhcmUgaGFyZCB0byBvYnRhaW4sIHdoZW4gaW4gZmFj dCB0aGUgY29zdCBpcyBvcmRlcnMgb2YgbWFnbml0dWRlIGxvd2VyIHRoYW4gb25lIGNlbnQsIGFu ZCBSSVIgcG9saWNpZXMgZXJlIGV4dHJlbWVseSBsaWJlcmFsPzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCB3b3VsZCBiZSBleHRyZW1lbHkg ZWFzeSB0byBzaW1wbHkgY2Fycnkgb3ZlciBwcmFjdGljZXMgdGhhdCB3ZSBoYXZlIGluIElQdjQg dG8gSVB2Ni4gQnV0IGJlY2F1c2UgYXBwbGljYXRpb25zIGFyZSBpbmNlbnRpdml6ZWQgdG8gYWRk IGFwcGxpY2F0aW9uIGNvbXBsZXhpdHkgaW4gb3JkZXIgdG8gd29yayBwcm9wZXJseSBvbiBhbGwg bmV0d29ya3MsIHRoZXJlIGlzIGEgcmlzayB0aGF0IHdlIG1pZ2h0IGdldA0KIHN0dWNrIHRoZXJl LCBhbmQgbmV2ZXIgYmUgYWJsZSB0byBlbGV2YXRlIG91cnNlbHZlcyBvdXQgb2YgdGhvc2UgcHJh Y3RpY2VzLiBJZiB0aGF0IGhhcHBlbnMgd2lsbCBrZWVwIHN1ZmZlcmluZyB0aGUgcHJvYmxlbXMg Y2F1c2VkIGJ5IElQIGFkZHJlc3Mgc2NhcmNpdHkgZXZlbiBhZnRlciBzY2FyY2l0eSBpcyBiYW5p c2hlZC4gVGhhdCB3b3VsZCBiZSBhIGJhZCBvdXRjb21lLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PZiBjb3Vyc2UgSSBtYXkgYmUgd3Jvbmcg YW5kIGEgb25lLWFkZHJlc3MtcGVyLWhvc3QgbW9kZWwgaXMgdGhlIHJpZ2h0IGNob2ljZS4gQnV0 IEkgZG9uJ3QgdGhpbmsgd2UgY2FuIHRlbGwgYXQgdGhlIG1vbWVudC4gT3ZlciB0aGUgeWVhcnMs IG5ldHdvcmsgYWRtaW5pc3RyYXRvcnMgdGhhdCBsZWFybiBhYm91dCBJUCAoYW5kIGFwcGxpY2F0 aW9uIGRldmVsb3BlcnMgdGhhdCB3cml0ZSBhcHBsaWNhdGlvbnMpDQogb24gZHVhbC1zdGFjayBu ZXR3b3JrcyB3aXRoIGEgbWl4IG9mIFNMQUFDIGFuZCBESENQdjYgd2lsbCBiZSBhYmxlIHRvIG1h a2UgYmV0dGVyIGNob2ljZXMgYmV0d2VlbiB0aGVzZSBwcm90b2NvbHMgdGhhbiB3ZSBjYW4gdG9k YXkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkNoZWVycyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkxvcmVuem88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+T24gRnJpLCBKYW4gMjAsIDIwMTcgYXQgMTo1OSBBTSwgQmVybmllIFZvbHogKHZv bHopICZsdDs8YSBocmVmPSJtYWlsdG86dm9sekBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj52 b2x6QGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+V2hpbGUg SSBwcm9iYWJseSBzaG91bGRuJ3Qgc2VuZCB0aGlzIGFzIGl0IGlzIGluIHRoZSBwb2xpdGljYWwg YW5kIG5vdCB0ZWNobmljYWwgc3BhY2UsIEkgZnJhbmtseSBhbSB2ZXJ5IGRpc2FwcG9pbnRlZCBp biBvbmUgY29tcGFueSB0aGF0LCB3aGlsZSB0cnlpbmcgdG8gcHJvbW90ZSBJUHY2IHVzYWdlLCBo YXMgYWxzbyB3b3JrZWQgdmVyeSBoYXJkIHRvIGxpbWl0DQogaXRzIHVzZSBieSBOT1Qgc3VwcG9y dGluZyBhIHByb3RvY29sIGRldmVsb3BlZCBieSB0aGUgSUVURi48YnI+DQo8YnI+DQpJJ20gYWxz byBzdXJwcmlzZWQgdGhhdCBvcmdhbml6YXRpb25zIGhhdmVuJ3QgcHVzaGVkIGhhcmRlciB0byBn ZXQgdGhhdCBjb21wYW55IHRvIGltcGxlbWVudCB0aGUgc3RhbmRhcmRzLiBJIHN1c3BlY3QgdGhv dWdoIHRoYXQgaXMgYmVjYXVzZSBJUHY2IGlzIG5vdCB5ZXQgJnF1b3Q7Y3JpdGljYWwmcXVvdDsg Zm9yIGRlcGxveW1lbnQuIFRoaXMgcHJvdmlkZXMgdGhlIGNvbXBhbnkgYW4gb3Bwb3J0dW5pdHkg dG8gcHVzaCB0aGVpciBhZ2VuZGEgKHdoYXRldmVyIGl0DQogbWF5IGJlKS48YnI+DQo8YnI+DQpJ IHdpbGwgYWRtaXQgdGhhdCBiZWluZyBESEMgV0cgY28tY2hhaXIsIGNvYXV0aG9yIG9mIHRoZSBz b21lIG9mIHRoZSBzdGFuZGFyZHMsIGFuZCBhbHNvIGEgdmVuZG9yIGRvZXMgYmlhcyBtZS48YnI+ DQo8c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PGJyPg0KPHNwYW4gY2xhc3M9ImhvZW56YiI+ LSBCZXJuaWU8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_60c76dc336c34899955a204cb336b5e2XCH150608nwnosboeingcom_-- From nobody Thu Jan 19 11:57:40 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10DD212950A for ; Thu, 19 Jan 2017 11:57:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ads292xpIV_w for ; Thu, 19 Jan 2017 11:57:35 -0800 (PST) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBF12120725 for ; Thu, 19 Jan 2017 11:57:34 -0800 (PST) Received: by mail-pg0-x22f.google.com with SMTP id 14so16654503pgg.1 for ; Thu, 19 Jan 2017 11:57:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=+llWGJyRF9yUUTGuZT5fI5G8Ds0CcUUdme3+UpdW6yA=; b=EkyH9dip4mYn9grVqMj2SkeDflx877Nh22Cih2Jfr4+Zs6mSk0sRANjyT+s38SZm+O 92I3CK4RQcblyBZxoHZUmBDiN5vC0qXjpaHqzpDLsmvJLZISDFWiy/UDYeC2rmy0qYnC eI60xmJDcMmcT4AVUjqfug12pSxwfz4idBaIsVcgQjVF3OQWvnCIG3WLwVffZPPI5FH5 Go1exjyqEeq+oybNH0fjr1t0d2jCwcf6evt/i1SPDUj2s9Nb0ptXLjCNlFqw9ocJ28FL MykbsOKqhTZ6GkpbayyPebfLZz85PLMOyilKifxFRWbZZ6A74AFrwQnASpxuTtvhuhr4 jm+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=+llWGJyRF9yUUTGuZT5fI5G8Ds0CcUUdme3+UpdW6yA=; b=ISS1nq27y0RKw3SB4xrSgXF15Zxf1JbqJe1Y43dRsXkSvky5ebcm3ljurptlScY/tC ccTckXAVSJb202ly3PgBCHavn/gW0SaAOQovcOBqUSvqlc3wC9cyc2zz6wMeRXhhBQjQ gDmkMv5y6Xc+Ua/DRSCsR4pket+RJEGOe6RbJrcgHqSM8wxN8XN/9ijAimEYEs/fVB7q qpKVNWCXFpx/UuoHhRrnUHsWZGSgMPEXvIcbhVj1/QIRjhaO1mKiuqFrbQ89DH7U4AZC t8VK6ztuW3E+I4OWna8nej+ZDiLnmir49c4Ls/RUivJmevWVTHDzZYzZCFy8PsIiFKiL x5kQ== X-Gm-Message-State: AIkVDXJyLRP2yW69pKJ6dDKXtVj9FHxNJAg+L8szVzSIc3GDplpo50cQ5hP54MXIBORZ/A== X-Received: by 10.84.141.164 with SMTP id 33mr15721327plv.86.1484855854327; Thu, 19 Jan 2017 11:57:34 -0800 (PST) Received: from [192.168.178.21] ([118.149.110.179]) by smtp.gmail.com with ESMTPSA id r78sm10778925pfl.63.2017.01.19.11.57.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Jan 2017 11:57:33 -0800 (PST) To: Lorenzo Colitti , Chuck Anderson References: <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <20170117.170305.74705723.sthaug@nethelp.no> <20170119132836.GO1862@angus.ind.wpi.edu> <20170119165247.GV2891@angus.ind.wpi.edu> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Fri, 20 Jan 2017 08:57:29 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Fernando Gont , v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 19:57:39 -0000 On 20/01/2017 06:08, Lorenzo Colitti wrote: > On Fri, Jan 20, 2017 at 1:52 AM, Chuck Anderson wrote: > >> Okay, so all your arguments above are working under the assumption >> that RA-based site multihoming can actually work in the real world. >> > > It is the only way to do PA-based multihoming without NAT and BGP. > > >> There are many practical problems with that approach. Ironically, a >> possible solution is identified RFC7157, which requires DHCPv6. >> > > Meh. draft-bowbakova-rtgwg-enterprise-pa-multihoming-01 is the way to go. Not completely unrelated to that, I think that RFC8028 would largely remove the dependency of RFC7157 on DHCPv6 (except for a split DNS scenario, which is unlikely to apply in a non-DHCPv6 network anyway). Brian From nobody Thu Jan 19 12:13:09 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB43129463 for ; Thu, 19 Jan 2017 12:13:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 tWncf4Vau6_j for ; Thu, 19 Jan 2017 12:13:06 -0800 (PST) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BF2A12943B for ; Thu, 19 Jan 2017 12:13:06 -0800 (PST) Received: by mail-ua0-x231.google.com with SMTP id 35so45341700uak.1 for ; Thu, 19 Jan 2017 12:13:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=fDKRZYvKNXxuQeILI6Cn0x6x7ZO4lYvqlSOZAKkTc/s=; b=hQn4h4bTLDsyfN5yJEkwJMP7x8PwfEDXmZYpUFK0tbIcd1cqYUWC5QMTpKXqf1ZvPH fb75lHWW3WRWL3qS4h/nePFhJATbM5Off06qh+CaeubieUFI9LbsczFHGrE20dfVxG2s um6Z1jDXVnOzbjC9NdgMEbdF7C2QarYe+uHx7NdT/JPS3Vm7vEIp+0kCZrc+bEJeMKxs M5bMANeAOc6TV/otL8im7dNcnAm12oSHAzuFhowuJtgmTagnkclQdxWt2XHmFuOfrev/ 0yu2Y+0+COWB9QNsRSKUC0tuT84LB3eg3a+gfoalBvOhZvUKVlzevpvNZ8UkNLGsu1Iw +wrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=fDKRZYvKNXxuQeILI6Cn0x6x7ZO4lYvqlSOZAKkTc/s=; b=KSJvm9KRHFIHozR+puCfa7NSava4v9vJwGv1nmCDUoFfzXyFgabCxiVICSfC/1STNx r7XV3Hk4X+MRsTILqIq+C3HSVDeYaC1h7pw257oUl8vIQD/rZZtRqeBV8PwNpbSL8Lfv +aKZJbpHPvjl0vYnXduhTCtRtGiEkYnU8qqYHY7KaLxw37Et0ctAn34piMza9Oxd2DX+ g6JWs61+/Lkbq3XzPlU7F24Hs/zuWCCOTvXX4DkpO7bqPOd16S59+1H4NsW51qJpOUVr SsPyn9vEsnxWUaTVjAA8gSW49zapjU/d87gMpZ030ciLP5/fPmGsCsCtxSLTHANnbMfU oNRw== X-Gm-Message-State: AIkVDXJ2Up18us/KioiU0qLqjCyzJsWrpslIWyJsjp9jX3xj6ATBlyELMwfemfRkP5E+cFk9F1el3faMjWb8aw== X-Received: by 10.176.82.54 with SMTP id i51mr5688256uaa.161.1484856785543; Thu, 19 Jan 2017 12:13:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.2.235 with HTTP; Thu, 19 Jan 2017 12:12:34 -0800 (PST) In-Reply-To: References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <99204933-5CB6-4E89-BD6A-FD40136DF6F5@steffann.nl> From: Mark Smith Date: Fri, 20 Jan 2017 07:12:34 +1100 Message-ID: To: Ted Lemon Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: james woodyatt , IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 20:13:07 -0000 On 20 January 2017 at 06:00, Ted Lemon wrote: > As one of the authors of RFC 3315, I feel I should chime in here to menti= on some discussion that has transpired since 3315 and related documents wer= e published, which I think has bearing on the question of whether to stuff = more options into RAs. > > To understand this, it is important to grasp the distinction between info= rmation that relates to the local network to which a host has connected, an= d information that relates to the host, independent of where it may connect= . In DHCPv4, many options fall into the latter category. Some DHCPv6 op= tions (e.g., the NTP servers option) do as well. > I'd say many of the DHCPv6 options do - I think only IA_NA and IA_TA are the only exceptions. > It is a really bad idea for the host to trust the local network to config= ure things like this. Do you really want the local Starbucks to provide yo= u with your source of time? Consequently, DHCP, which is really an infras= tructure protocol, is a poor choice for configuring such parameters. Stuf= fing those parameters into ND would be compounding the mistake. Please do= not do this. > So what is the alternative? Hosts have trusted the networks they attach to for more than being given an address to since at least BOOTP. Trusting the network being attached to for service parameters seems to be a fundamental and many decade old assumption, and is the common practice for IPv4 on public less trusted networks. Specific to DNS, I think I'd currently trust Starbucks for NTP more than DNS. My device might have multiple NTP and other time sources, so the trust of the Starbucks NTP time source can be evaluated. I don't think DNSSEC is deployed widely enough to be entirely confident that Starbucks won't be changing DNS resolver responses if it is in their interests. Are we moving to a model where the only trust of the local network is (and only should be) for addressing information? Are we then locked into the upper services, such as DNS and NTP, that the device vendor chooses because the device vendor doesn't let us change them? Regards, Mark. From nobody Thu Jan 19 12:31:34 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08FD9129573 for ; Thu, 19 Jan 2017 12:31:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.501 X-Spam-Level: X-Spam-Status: No, score=-7.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wpi.edu 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 8YSWr3-f50O0 for ; Thu, 19 Jan 2017 12:31:31 -0800 (PST) Received: from MAIL1.WPI.EDU (mail1.wpi.edu [130.215.36.91]) by ietfa.amsl.com (Postfix) with ESMTP id 7111C129459 for ; Thu, 19 Jan 2017 12:31:30 -0800 (PST) Received: from MAIL1.WPI.EDU (MAIL1.WPI.EDU [130.215.36.91]) by MAIL1.WPI.EDU (8.15.1/8.15.1) with ESMTP id v0JKVSE7001073; Thu, 19 Jan 2017 15:31:28 -0500 DKIM-Filter: OpenDKIM Filter v2.10.3 MAIL1.WPI.EDU v0JKVSE7001073 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wpi.edu; s=_dkim; t=1484857888; bh=D+g8LvxYUWeTuKnXc9sKxPrI8qhNb29umNdi8tnxzMY=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=W8HKlZb1xUUrho7US2WzKqyRZnCD+pKnl+KcWlqvUNhhNH+k9eLhSgTOD5AflAJrM TJQoOR+AI87vrsfSfemI+b6WlSKvLxIDfHO+bsXLuhEd7F148D3GhHjwicRcMjVe/F UTfd6Z7EFpmeApLWyG6x5N2h2lC6QhsCgJtHX1Z4= Received: from milter1.wpi.edu (milter1.wpi.edu [130.215.36.49]) by MAIL1.WPI.EDU (8.15.1/8.15.1) with ESMTP id v0JKVSOm001070; Thu, 19 Jan 2017 15:31:28 -0500 Received: from angus.ind.wpi.edu (angus.ind.wpi.edu [130.215.130.21]) by milter1.wpi.edu (8.14.4/8.14.4) with ESMTP id v0JKVQGV010217; Thu, 19 Jan 2017 15:31:27 -0500 (envelope-from cra@WPI.EDU) Received: by angus.ind.wpi.edu (Postfix, from userid 10002) id 9C6CDDF5F3; Thu, 19 Jan 2017 15:31:26 -0500 (EST) Date: Thu, 19 Jan 2017 15:31:26 -0500 From: Chuck Anderson To: Lorenzo Colitti Message-ID: <20170119203126.GX2891@angus.ind.wpi.edu> References: <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <20170117.170305.74705723.sthaug@nethelp.no> <20170119132836.GO1862@angus.ind.wpi.edu> <20170119165247.GV2891@angus.ind.wpi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-PerlMx-Spam: Gauge=IIIIIIII, Probability=8%, Report=' MULTIPLE_RCPTS 0.1, HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1000_LESS 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, BODY_SIZE_800_899 0, DATE_TZ_NA 0, FROM_EDU_TLD 0, IN_REP_TO 0, LEGITIMATE_SIGNS 0, MSG_THREAD 0, MULTIPLE_REAL_RCPTS 0, NO_URI_HTTPS 0, REFERENCES 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CC_NAME 0, __CC_NAME_DIFF_FROM_ACC 0, __CC_REAL_NAMES 0, __CD 0, __CT 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __HAS_CC_HDR 0, __HAS_FROM 0, __HAS_MSGID 0, __IN_REP_TO 0, __MIME_TEXT_ONLY 0, __MIME_TEXT_P 0, __MIME_TEXT_P1 0, __MIME_VERSION 0, __MULTIPLE_RCPTS_CC_X2 0, __NO_HTML_TAG_RAW 0, __PHISH_SPEAR_STRUCTURE_1 0, __REFERENCES 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __SUBJ_ALPHA_NEGATE 0, __TO_MALFORMED_2 0, __TO_NAME 0, __TO_NAME_DIFF_FROM_ACC 0, __TO_REAL_NAMES 0, __URI_NO_WWW 0, __URI_NS , __USER_AGENT 0' Archived-At: Cc: Fernando Gont , v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 20:31:33 -0000 On Fri, Jan 20, 2017 at 02:08:07AM +0900, Lorenzo Colitti wrote: > On Fri, Jan 20, 2017 at 1:52 AM, Chuck Anderson wrote: > > > Okay, so all your arguments above are working under the assumption > > that RA-based site multihoming can actually work in the real world. > > > > It is the only way to do PA-based multihoming without NAT and BGP. > > > > There are many practical problems with that approach. Ironically, a > > possible solution is identified RFC7157, which requires DHCPv6. > > > > Meh. draft-bowbakova-rtgwg-enterprise-pa-multihoming-01 is the way to go. Boo. "How a host should make good decisions about source address selection in a multihomed site is not a solved problem. We do not attempt to solve this problem in this document." From nobody Thu Jan 19 12:53:56 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C38E129610 for ; Thu, 19 Jan 2017 12:53:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 SiBxA3ocyx8F for ; Thu, 19 Jan 2017 12:53:54 -0800 (PST) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28AC2129598 for ; Thu, 19 Jan 2017 12:53:54 -0800 (PST) Received: by mail-ua0-x235.google.com with SMTP id y9so46360508uae.2 for ; Thu, 19 Jan 2017 12:53:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=qK6w5WpiV+q4/9UJ3Ep+YGpuE3aSm7m14vHFPR+uGVw=; b=ihksqyGA8RSgqjb5I7PFu6ZUkjWMBvDkLu+PTzPTF3+3LHYRxebx+uWbLvULjwhZcA EKLDOqVKAEBeSSEVLrJ52PQH57iESDMacEtmyMoJI89uhbAUbEboa2huwRjbzvjOjPRj JF3prmf5Fh7TzYipaziwxyNwF1ygahlgt+1WlJQ/IuuQ7mMkK/OSh+xPFPeqK7njYjMb Dov2rKnLbfIH6xWjFwlDwidRQd7AbJNLbRUw1F8XwO9hT/ExsCTRuspoFfeePc8E6kkM b+gRrqQ4qeaFJxgjnWGQRBjZPKECMd9P8HJF8j845koRGgD6AlEwDNkRUknAwXxjP5P9 Hz5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=qK6w5WpiV+q4/9UJ3Ep+YGpuE3aSm7m14vHFPR+uGVw=; b=h66TNC8A/ki0MXICkU2aJVHcKcYKLx9HHKkRxk7fE5bfkaSHkxL22Woe7gzq4Yk7R7 yDFrNnSWbM3Ouan9n9SqVEXBD/oxKT5K8N4FVjMqzOEpczER+/SUlHHYJxcd6K/qa45R Wf3iz5QF2Atgdl/BKdjxeyMoMzTzBXyqWUCEEoGjNnzUIKNe++GKdzRPSVKnWJu79YO7 H+mJuwdiZ3Iv348pjjj9wW5gq61mo54p49UuxJh16mcugpyrh25dm2JnhZqkwVPJ6Ui7 pOocnGeJ961nr0bWL3VrIYkFKzEv25Yw65Z3dRJH1W77+L2lMXmvkVuqU9S86SNLT2id GPGg== X-Gm-Message-State: AIkVDXL7OJGf0i0qunn9y+upKRaU8mLhFOio8TdaG7pMYIwtprZ/3TF1ZJJlwivBm/gnwf4H0CxwHtJ9fqKW6g== X-Received: by 10.176.83.153 with SMTP id k25mr5009601uaa.141.1484859233193; Thu, 19 Jan 2017 12:53:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.2.235 with HTTP; Thu, 19 Jan 2017 12:53:22 -0800 (PST) In-Reply-To: References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <99204933-5CB6-4E89-BD6A-FD40136DF6F5@steffann.nl> From: Mark Smith Date: Fri, 20 Jan 2017 07:53:22 +1100 Message-ID: To: Sander Steffann Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Fernando Gont , IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 20:53:55 -0000 On 19 January 2017 at 20:50, Sander Steffann wrote: > Hi Mark, > >> So none this is religious, or if people participating are being >> religious, then they shouldn't be participating. Engineering is >> supposed to be about being objective, and debating and weighing up the >> pros and cons of various options. > > Thanks, well said. > >> Implementing every option every >> where to try to provide everybody with their favourite method >> ("provide all options in both RA and DHCPv6") just creates complexity, >> confusion, more code to write and more things that can break. > > That's a valid concern. I suggested using the same options for both RA an= d DHCPv6 exactly for this reason: to keep things simpler. More is never simpler. If host parameters are duplicated across RAs and DHCPv6, there is no single source of truth anymore. The Internet is supposed to be application transparent - application (and transport) protocols only reside in the hosts, the Internet is just a dumb packet forwarding network shunting around packets carrying payloads it doesn't care about. The devices in the network (the packet forwarding routers) do not have to have their software or hardware upgraded to support new applications. Applications only reside on/in hosts. I think the same transparency model applies and should apply to host configuration, what I'd call "Internet application configuration transparency". "Internet Transparency and Application Configuration" https://tools.ietf.org/html/draft-smith-v6ops-ce-dhcpv6-transparency-00#sec= tion-2 > With the current direction things seem to be moving to I'm afraid we're g= oing to end up with different options for DNS, NTP, default gateway etc in = both protocols, and that would be really bad. > >> I think when a discussion like this gets to this point, it is worth >> revisiting the problem or problems being solved. >> >> I think there are two problems to be/being solved: >> >> - providing hosts with specific link layer 3 parameters, meaning >> parameters that may be incorrect, irrelevant and unrelated on a >> different link, and shouldn't be made available on a different link >> (if the values are the same across different links, they are different >> instances of the values that happen to be the same value) >> >> - providing hosts with upper layer parameters that are not specific to >> and independent of the link the host is currently attached to >> >> RA options, with exception to the RDNSS options, all solve the first >> problem, and it is right that a local device attached to the link >> provides the parameters for the link. Address assignment is a link >> specific subset problem, so providing link layer specific parameters >> to suit address generation/assignment on the link is also solving this >> problem. >> >> DHCPv6 options, with exception to the IA_NA/IA_TA options, all solve >> the second problem, and since they're not link specific, and can be >> host specific, it means that regardless of where the host attaches, it >> isn't a requirement that the device providing them resides on the same >> link as the host, as long as the configuration request messages from >> the host can reach the configuration server (which we solve with an >> on-link DHCPv6 relay). > > That's not always true. For example the NTP server advertised though DHCP= v6 might only be reachable from that specific link. Same for DNS servers, A= FTR, MAP settings and other options. So there are definitely exceptions. > > I love the original model of RA for network stuff and stateless DHCPv6 fo= r everything else. For new people it took some getting used to, but it was = a clear conceptual model. But for example the push for RDNSS and DHCPv6 def= ault gateway, DS-Lite and MAP options shows that there is a demand for more= diversity in both directions. > I don't think they're critically analysing the operational consequences of their preferences. While understandable, that's religion rather than engineering. > So maybe we should take a step back and think about the conceptual model = again. That's all I'm suggesting. I think having two different protocols (R= A and stateless DHCPv6) that are starting to overlap more and more is a bad= thing. Maybe it's time to see if we can define a new conceptual model wher= e we combine the two... > > Is there really such a difference between layer-3 settings (RA) and layer= -4+ settings (DHCPv6) that we need to keep those protocols separate? Or do = we need one set of protocols for layer-3+ with both a multicast-push model = (RA) and a unicast-pull model (DHCPv6)? It's a different conceptual model, = so it's not something that can/should be changed lightly. On the other hand= the layer3/4+ distinction seems to be fading already. > > But I think it's really important that we revisit this, and rather sooner= than later. I personally am perfectly fine with the original model, but I = also see (mostly) enterprises that seem to push for the other model and may= be that isn't so bad and we should embrace that and make it official so we = can make it consistent... > The next generation after the "IPv4+NAT" generation won't care. They'll just accept IPv6 the way it is. Regards, Mark. From nobody Thu Jan 19 13:09:55 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0637A129620 for ; Thu, 19 Jan 2017 13:09:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 qiwVdIdN1NBN for ; Thu, 19 Jan 2017 13:09:26 -0800 (PST) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E03F12961E for ; Thu, 19 Jan 2017 13:09:26 -0800 (PST) Received: by mail-yw0-x235.google.com with SMTP id v200so49860695ywc.3 for ; Thu, 19 Jan 2017 13:09:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4khRtfbb0BqR17hfwdIIKpSyMdVOEuHpzGmaDJCrNTk=; b=cSFhP8/9cDq0/MxUfyAn7w3VA/QbMAK/QpoZ/QLviHAjMchwo0z/2v+3F2hEPGZaNT ktnTo5ptyrw1ABGcPbqrSFPSpHhattZ4B3xd7/VKH9ua3DDgUrRoit8Cf1H+6ugy4SLX y6hQ2vQTq/k1vgpILez+Nf8utwE2qJM1xZPFa+GRL349BVR4oEAYgH4Ulw/qCsRWGRCZ uM243yYf5kGeDJX/jDpTKHjj5Gd4CJEaBd0PZWmkJ2Xw/T3XsdfpQ3RCigGkfgrPOzDn iCJSnWTjw50r6U+47mYkwEokEp6TWWeEgdn2sORIchTQLC8HTFibiWPfXj7u3/YZySwq jwIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4khRtfbb0BqR17hfwdIIKpSyMdVOEuHpzGmaDJCrNTk=; b=Lgl2wYMFMUQVFRJBhoYIwmWaX06hAfirQk0FLlD7guPrK3B5Qa9vgwZh9CDufWPB/3 IVkRYdjrFjvO6xzWIJ6JX8pyaNbQDOr47IkYRBfW/jLH6vUdUI6jlQC3i28ywSfbIJXi CBGE2kNhhgSGXG8iz62nYptuNZmlonPGTVv828bH9ghTckdwMqlNL28EP5cryI0CKKwP r0jYSIS8UzHCUcsSVVEe76jBv9Ifm0LuGUaCE5M128jFwN9Qp7QJffZzTUFyvppczUXD VhemVvR9dVdb7LK7MoDfAPgxRc9UYBgr402WYJbXpcjC04Mj+bp5XSfXZ7yT5SI5CXLE UvLA== X-Gm-Message-State: AIkVDXK0CaFYB4CXZqununbBig7P3ElCsMnTAd+bofydIhBAiovgVCOCHeWPZhYfzLqH5Q== X-Received: by 10.55.43.74 with SMTP id r71mr9442689qkh.306.1484860165532; Thu, 19 Jan 2017 13:09:25 -0800 (PST) Received: from [192.168.1.228] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id b16sm4105537qka.9.2017.01.19.13.09.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Jan 2017 13:09:24 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ted Lemon In-Reply-To: Date: Thu, 19 Jan 2017 16:09:22 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <99204933-5CB6-4E89-BD6A-FD40136DF6F5@steffann.nl> To: Mark Smith X-Mailer: Apple Mail (2.3259) Archived-At: Cc: james woodyatt , IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 21:09:31 -0000 On Jan 19, 2017, at 3:12 PM, Mark Smith wrote: > I'd say many of the DHCPv6 options do - I think only IA_NA and IA_TA > are the only exceptions. Providing the IP address of a recursive resolver isn't so bad, because = you have DNSSEC to protect you. :) > So what is the alternative? For NTP, you should probably be using the NTP server your vendor = configured, unless you have your own, in which case you should be using = that. For SMTP, you should be using the SMTP server your email = provider offers, not the one the network offers. For print, you should = probably be using DNSSD, not DHCP. Etc. You should have an = authenticated trust relationship with any service you use, so that you = can tell if you are being spoofed. > Hosts have trusted the networks they attach to for more than being > given an address to since at least BOOTP. Trusting the network being > attached to for service parameters seems to be a fundamental and many > decade old assumption, and is the common practice for IPv4 on public > less trusted networks. I don't know of any non-infrastructure devices that use the = DHCP-provided NTP server. > Specific to DNS, I think I'd currently trust Starbucks for NTP more > than DNS. My device might have multiple NTP and other time sources, so > the trust of the Starbucks NTP time source can be evaluated. I don't > think DNSSEC is deployed widely enough to be entirely confident that > Starbucks won't be changing DNS resolver responses if it is in their > interests. You should check this assumption. I suspect you are using a fixed NTP = server, not one configured via DHCP. > Are we moving to a model where the only trust of the local network is > (and only should be) for addressing information? Are we then locked > into the upper services, such as DNS and NTP, that the device vendor > chooses because the device vendor doesn't let us change them? It would be nice to have a host configuration protocol that is homed = rather than ad-hoc. But we don't have that. As it stands, yes, you = either need to trust the vendor config or update it manually. Unless = your device is an infrastructure device, trusting the network is a = _really_ bad idea. Maybe even then.= From nobody Thu Jan 19 13:46:35 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83E9512962F for ; Thu, 19 Jan 2017 13:46:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.72 X-Spam-Level: X-Spam-Status: No, score=-17.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 lYiA8K5svpqj for ; Thu, 19 Jan 2017 13:46:32 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 080BF12947E for ; Thu, 19 Jan 2017 13:46:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30880; q=dns/txt; s=iport; t=1484862390; x=1486071990; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=gNUJQ1Xw3HI5CKiUAIfNxLout3suZIydkftTxf4Xk1w=; b=AVcDuK9ZaiDYzsi46L+DbBndypTGLTOuqc02eFOye/pm3Tzy3xOkrOqQ SVDi9MwoXWbgAcPOmR03fAVnoLqxLbGT/VAjx30wQY2SZj2Ia3qJaoINF avM7rhGa+dlQlo8SrpGPCNbMsf/MRB6xltKCVNPiQ4uunU8166Y3WcngV 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B2AQBwM4FY/4gNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9BDwEBAQEBH2CBCQeDSooIkgRtlD+CDCqFeAIagWc/FAECAQE?= =?us-ascii?q?BAQEBAWMohGkBAQEEIwpMEAIBCBEEAQEhBwMCAgIwFAkIAgQOBQgMiG8OsACCJ?= =?us-ascii?q?YpMAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWLOYQmDS0PEIJQgl4Fm0QBhmCDGId?= =?us-ascii?q?jggCIXIYbkm8BHzhEgQIVOoQ2AgMcgWBzhncBJQSBBoENAQEB?= X-IronPort-AV: E=Sophos;i="5.33,255,1477958400"; d="scan'208,217";a="195458954" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Jan 2017 21:46:29 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v0JLkT4g026105 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 19 Jan 2017 21:46:29 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 19 Jan 2017 15:46:28 -0600 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1210.000; Thu, 19 Jan 2017 15:46:28 -0600 From: "Bernie Volz (volz)" To: Lorenzo Colitti Thread-Topic: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem Thread-Index: AdJsHl8eSkgq9pmdSH+a6rrO1byUfgEH4nKAAA8QH4AABHryAAAFi+6AABamygAAAefdAAACPr2AAAG7wYAAHikwgAA/SxMAAAG7nIAABWYVAAAMguqg//+p0ACAACVXYA== Date: Thu, 19 Jan 2017 21:46:28 +0000 Message-ID: <5a275aeadcd943e38d443735acb761a4@XCH-ALN-003.cisco.com> References: <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <20170117.170305.74705723.sthaug@nethelp.no> <20170119132836.GO1862@angus.ind.wpi.edu> <20170119165247.GV2891@angus.ind.wpi.edu> <50240d7e06c3427cabaac463a95cdac2@XCH-ALN-003.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.1.200] Content-Type: multipart/alternative; boundary="_000_5a275aeadcd943e38d443735acb761a4XCHALN003ciscocom_" MIME-Version: 1.0 Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 21:46:34 -0000 --_000_5a275aeadcd943e38d443735acb761a4XCHALN003ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTG9yZW56bzoNCg0KSSBkbyByZWdyZXQgbm90IGJlaW5nIG1vcmUgYWN0aXZlIHdoZW4gUkZD IDc5MzQgd2FzIGJlaW5nIGRyYWZ0ZWQgYXMgSSB0aGluayB0aGVyZSBhcmUgc29tZSB0aGluZ3Mg YWJvdXQgREhDUHY2IHRoYXQgYXJlIGEgYml0IG9mZi4NCg0KICAgICAgICAgIEl0IGlzIGFsc28g dGVjaG5pY2FsbHkgcG9zc2libGUgZm9yIGEgY2xpZW50DQogICAgICB0byByZXF1ZXN0IGFkZGl0 aW9uYWwgYWRkcmVzc2VzIHVzaW5nIGEgZGlmZmVyZW50IERIQ1AgVW5pcXVlDQogICAgICBJZGVu dGlmaWVyIChEVUlEKSwgdGhvdWdoIHRoZSBESENQdjYgc3BlY2lmaWNhdGlvbiBpbXBsaWVzIHRo YXQNCiAgICAgIHRoaXMgaXMgbm90IGV4cGVjdGVkIGJlaGF2aW9yIChbUkZDMzMxNV0sIFNlY3Rp b24gOTxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMzMxNSNzZWN0aW9uLTk+KS4NCg0K VGhlIHdheSBhIGNsaWVudCBjYW4gZ2V0IG1hbnkgYWRkcmVzc2VzIGlzIHNpbXBseSB0byBzZW5k IGluIG11bHRpcGxlIElBX05BIChvciBJQV9UQSBvciBJQV9QRCkgb3B0aW9ucyB3aXRoIGRpZmZl cmVudCBJQUlEIHZhbHVlcy4gVGhlcmUgaXMgbm8gbmVlZCB0byBjaGFuZ2UgdGhlIERVSUQuDQoN Cg0KICAgICAgICAgICBUaGUgbWF4aW11bSBudW1iZXIgb2YgSVB2NiBhZGRyZXNzZXMgdGhhdCBj YW4gYmUgcHJvdmlkZWQNCg0KICAgICAgaW4gYSBzaW5nbGUgREhDUHY2IHBhY2tldCwgZ2l2ZW4g YSB0eXBpY2FsIE1UVSBvZiAxNTAwIGJ5dGVzIG9yDQoNCiAgICAgIHNtYWxsZXIsIGlzIGFwcHJv eGltYXRlbHkgMzANCg0KQnV0IGEgY2xpZW50IGlzIGZyZWUgdG8gc2VuZCBtYW55IHNlcGFyYXRl IHRyYW5zYWN0aW9ucyAobXVsdGlwbGUgcGFja2V0cykuIEZvciBleGFtcGxlLCBvbmUgYXBwcm9h Y2ggd291bGQgYmUgdG8gc2VuZCBhIG5ldyByZXF1ZXN0IHdoZW5ldmVyIGEgbmV3IGFkZHJlc3Mg aXMgbmVlZGVkIOKAkyB0aGlzIHdvdWxkIGJlIGFuIElBX05BIChmb3Igbm9uLXRlbXBvcmFyeSBh ZGRyZXNzKSB3aXRoIGEgdW5pcXVlIElBSUQuIEFuZCwgdGhhdCBtaWdodCBiZSBtdWNoIGVhc2ll ciB3aGVuIHlvdSBoYXZlIGR5bmFtaWMgbmVlZHMgKGkuZS4sIGRldmljZSBiZWluZyBhZGRlZCBv dmVyIHRpbWUpLg0KDQpBbmQsIGVhY2ggdHJhbnNhY3Rpb24gZG9lcyBub3QgbmVlZCB0byBzdGFy dCB3aXRoIHRoZSBzZXJ2ZXIgZGlzY292ZXJ5IHByb2Nlc3Mgc2luY2UgdGhhdCBoYXMgYWxyZWFk eSBiZWVuIGRvbmUg4oCTIHRoZXkgY2FuIHN0YXJ0IHdpdGggYSBSZXF1ZXN0ICgyIG1lc3NhZ2Ug ZXhjaGFuZ2UpLg0KDQpTYWRseSwgd2UgbWF5IGhhdmUgbWFkZSB0aGluZ3MgZXZlbiBhIGJpdCB3 b3JzZSB3aXRoIHRoZSBpbnRyb2R1Y3Rpb24gb2YgUkZDIDc1NTAgYXMgdGhpcyBwcm9tb3RlcyB1 c2luZyBhIHNpbmdsZSB0cmFuc2FjdGlvbiB3aGVuIGFza2luZyBmb3IgbXVsdGlwbGUgdGhpbmdz IChJQV9OQSArIElBX1BEIGlzIHRoZSBjbGFzc2ljIGV4YW1wbGUpLiBCdXQgdGhlIGdvYWwgb2Yg UkZDIDc1NTAgd2FzIHRvIG1ha2UgdGhlIEN1c3RvbWVyIEVkZ2UgKENFKSByb3V0ZXIgKGRlc2Ny aWJlZCBpbiBSRkM3MDg0KSBtb2RlbCBzaW1wbGVyIOKAkyBlc3BlY2lhbGx5IGluIGNhc2VzIHdo ZXJlIG5vdCBib3RoIGFuIGFkZHJlc3MgYW5kIGRlbGVnYXRlZCBwcmVmaXggbWlnaHQgYmUgYXZh aWxhYmxlLiBBbmQsIGlmIGRvZXNu4oCZdCBwcmVjbHVkZWQgdGhlIHNlcGFyYXRlIHRyYW5zYWN0 aW9uIG1vZGVsLg0KDQoNCk5laXRoZXIgb2YgdGhlIHN0YXRlbWVudHMgaW4gdGhlIFJGQyBpcyB0 ZWNobmljYWxseSB3cm9uZyAoYXMgY2hhbmdpbmcgdGhlIERVSUQgaXMgY2VydGFpbmx5IG9uZSB3 YXkgdG8gYWNjb21wbGlzaCB0aGF0IGdvYWwsIGFuZCB0aGUgbGltaXQgZm9yIGEgc2luZ2xlIHBh Y2tldCBpcyBjb3JyZWN0KS4gQnV0IGl0IGp1c3QgbGVhdmVzIHRoZSB3cm9uZyBpbXByZXNzaW9u IGFib3V0IERIQ1B2Ni4gV2UgZGVzaWduZWQgaXQgdG8gYWxsb3cgTE9UUyBvZiBhZGRyZXNzZXMg cGVyIGNsaWVudCBhbmQgYmUgdmVyeSBmbGV4aWJsZSBpbiBob3cgdGhvc2UgYWRkcmVzc2VzIGFy ZSDigJxncm91cGVk4oCdIChpLmUuLCBieSBJQV8qIHR5cGUgYW5kIElBSUQpLg0KDQpBbmQsIHll cyB0aGlzIGlzIG1vcmUgY29kZSBhbmQgb3ZlcmhlYWQgdG8ganVzdCBoYXZpbmcgYSAvNjQgYXZh aWxhYmxlIGFuZCBidWlsZGluZyBhbiBhZGRyZXNzIHdoZW5ldmVyIGl0IGlzIG5lZWRlZCAodGhh dOKAmXMgYSBmZXcgbGluZXMgb2YgY29kZSB0byB3cml0ZSBhbmQgZXhlY3V0ZSkg4oCTIG5vIGV4 dHJhIGV4dGVybmFsIGNvbW11bmljYXRpb24gbmVjZXNzYXJ5Lg0KDQoNCi0gICAgICAgICAgQmVy bmllDQoNCkZyb206IExvcmVuem8gQ29saXR0aSBbbWFpbHRvOmxvcmVuem9AZ29vZ2xlLmNvbV0N ClNlbnQ6IFRodXJzZGF5LCBKYW51YXJ5IDE5LCAyMDE3IDEyOjQzIFBNDQpUbzogQmVybmllIFZv bHogKHZvbHopIDx2b2x6QGNpc2NvLmNvbT4NCkNjOiBDaHVjayBBbmRlcnNvbiA8Y3JhQHdwaS5l ZHU+OyBGZXJuYW5kbyBHb250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+OyB2Nm9wcyBsaXN0IDx2 Nm9wc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbdjZvcHNdIGRyYWZ0LWlldGYtdjZvcHMtZGhj cHY2LXNsYWFjLXByb2JsZW0NCg0KQmVybmllLA0KDQpoYXZlIHlvdSByZWFkIFJGQyA3OTM0PyBJ dCBsaXN0cyBhIG51bWJlciBvZiByZWFzb25zIHdoeSBpdCBpcyBub3QgcmVjb21tZW5kZWQgZm9y IG5ldHdvcmtzIHRvIHN1cHBvcnQgb25seSBESENQdjYgYWRkcmVzcyBhc3NpZ25tZW50IHZpYSBJ QV9OQS4NCg0KSSBkb24ndCB0aGluayBESENQdjYgaW4gaXRzZWxmIGlzIGEgcHJvYmxlbS4gV2hp bGUgaXQgZG9lcyBzdWZmZXIgZnJvbSB0aGUgbGltaXRhdGlvbnMgSSBvdXRsaW5lZCBpbiBteSBl YXJsaWVyIG1lc3NhZ2UsIGl0IGlzIGZsZXhpYmxlIGFuZCBleHRlbnNpYmxlIHRvIHdheSBtb3Jl IGluZm9ybWF0aW9uIHRoYW4gUkFzIGNhbiBjYXJyeS4gSXQncyBhbHNvIHdpZGVseSBzdXBwb3J0 ZWQuIEJ1dCBJIHJlYWxseSB0aGluayBJQV9OQSBpcyBub3QgYXBwcm9wcmlhdGUgZm9yIElQdjYg YXNzaWdubWVudCwgZm9yIHRoZSByZWFzb25zIHRoYXQgdGhlIGF1dGhvcnMgYW5kIHRoZSBXRyBv dXRsaW5lIGluIFJGQzc5MzQuDQoNClVuZm9ydHVuYXRlbHksIGZvciBtYW55LCBkZWNhZGVzIG9m IG9wZXJhdGlvbmFsIGZhbWlsaWFyaXR5IGFuZCB2ZW5kb3Igc3VwcG9ydCB3aXRoIElQdjQgbmV0 d29ya3MsIHdoZXJlIHRoZSBvbmx5IHdheSB0byBnZXQgYW4gSVAgYWRkcmVzcyAoYW5kIG9ubHkg ZXZlciBPTkUgYWRkcmVzcykgd2FzIERIQ1AsIG1ha2UgaXQgdmVyeSBoYXJkIHRvIHRoaW5rIG9m IGFueSBvdGhlciBhZGRyZXNzIGFzc2lnbm1lbnQgbWVjaGFuaXNtLiBTTEFBQyBpcyByZWd1bGFy bHkgZGlzbWlzc2VkIGFzIG91dGxhbmRpc2ggYW5kIGluc2VjdXJlLCAvNjQgc3VibmV0cyBhcyB3 YXN0ZWZ1bCwgYW5kIHRoZSBpbnNpc3RlbmNlIHRoYXQgSVB2NCBhbmQgSVB2NiBkZW1hbmQgZGlm ZmVyZW50IGxpbmstYWRkcmVzc2luZyBwcmFjdGl2ZXMgYXMgcmVsaWdpb24uICJXaHkgY2FuJ3Qg d2UganVzdCB1c2UgREhDUCIsIGFzIGFuIGVhcmxpZXIgbWVzc2FnZSBwdXQgaXQuIFVuZm9ydHVu YXRlbHkgdGhlIHRydXRoIGlzIG11Y2ggbW9yZSBjb21wbGV4IHRoYW4gdGhhdC4NCg0KSWYgdGhl IEludGVybmV0IGlzIGV2ZW50dWFsbHkgdG8gcmVhcCB0aGUgZnVsbCBiZW5lZml0cyBvZiBJUHY2 LCB0aGVuIHdlIGFzIGEgdGVjaG5pY2FsIGNvbW11bml0eSBhbmQgYXMgYW4gaW5kdXN0cnkgbmVl ZCB0byBnaXZlIGEgY2hhbmNlIHRvIGEgbmV3IGFkZHJlc3NpbmcgbW9kZWwgd2hlcmUgaG9zdHMg Y2FuIHVzZSBhcyBtYW55IElQdjYgYWRkcmVzc2VzIGFzIHRoZXkgbmVlZC4gUmlnaHQgbm93LCB0 aGF0IG1lYW5zIFNMQUFDLiBUaGUgZmFjdCBvZiB0aGUgbWF0dGVyIGlzIHRoYXQgaXQgU0xBQUMn cyBzZWN1cml0eSBwcm9wZXJ0aWVzIGFyZSBub3Qgc3Vic3RhbnRpYWxseSB3b3JzZSB0aGFuIElB X05BLCBhbmQgYW55b25lIHdobyBzYXlzIGRpZmZlcmVudGx5IHNob3VsZCByZWFkIFJGQyA3OTM0 IHNlY3Rpb24gOS4xLCBvZiB3aGljaCBJIGhhdmUgbm90IHlldCBzZWVuIGFueSByZWJ1dHRhbCwg Y29udmluY2luZyBvciBvdGhlcndpc2UuIEFuZCBhcyBmb3IgLzY0cyBiZWluZyB3YXN0ZWZ1bCAt IHlvdSBzYXcgdGhlIGVhcmxpZXIgbWVzc2FnZXMgaW4gdGhpcyBjb252ZXJzYXRpb24gdGhhdCBh c3NlcnRlZCB0aGF0IHByZWZpeGVzIGNvc3QgbW9uZXkgb3IgdGhleSBhcmUgaGFyZCB0byBvYnRh aW4sIHdoZW4gaW4gZmFjdCB0aGUgY29zdCBpcyBvcmRlcnMgb2YgbWFnbml0dWRlIGxvd2VyIHRo YW4gb25lIGNlbnQsIGFuZCBSSVIgcG9saWNpZXMgZXJlIGV4dHJlbWVseSBsaWJlcmFsPw0KDQpJ dCB3b3VsZCBiZSBleHRyZW1lbHkgZWFzeSB0byBzaW1wbHkgY2Fycnkgb3ZlciBwcmFjdGljZXMg dGhhdCB3ZSBoYXZlIGluIElQdjQgdG8gSVB2Ni4gQnV0IGJlY2F1c2UgYXBwbGljYXRpb25zIGFy ZSBpbmNlbnRpdml6ZWQgdG8gYWRkIGFwcGxpY2F0aW9uIGNvbXBsZXhpdHkgaW4gb3JkZXIgdG8g d29yayBwcm9wZXJseSBvbiBhbGwgbmV0d29ya3MsIHRoZXJlIGlzIGEgcmlzayB0aGF0IHdlIG1p Z2h0IGdldCBzdHVjayB0aGVyZSwgYW5kIG5ldmVyIGJlIGFibGUgdG8gZWxldmF0ZSBvdXJzZWx2 ZXMgb3V0IG9mIHRob3NlIHByYWN0aWNlcy4gSWYgdGhhdCBoYXBwZW5zIHdpbGwga2VlcCBzdWZm ZXJpbmcgdGhlIHByb2JsZW1zIGNhdXNlZCBieSBJUCBhZGRyZXNzIHNjYXJjaXR5IGV2ZW4gYWZ0 ZXIgc2NhcmNpdHkgaXMgYmFuaXNoZWQuIFRoYXQgd291bGQgYmUgYSBiYWQgb3V0Y29tZS4NCg0K T2YgY291cnNlIEkgbWF5IGJlIHdyb25nIGFuZCBhIG9uZS1hZGRyZXNzLXBlci1ob3N0IG1vZGVs IGlzIHRoZSByaWdodCBjaG9pY2UuIEJ1dCBJIGRvbid0IHRoaW5rIHdlIGNhbiB0ZWxsIGF0IHRo ZSBtb21lbnQuIE92ZXIgdGhlIHllYXJzLCBuZXR3b3JrIGFkbWluaXN0cmF0b3JzIHRoYXQgbGVh cm4gYWJvdXQgSVAgKGFuZCBhcHBsaWNhdGlvbiBkZXZlbG9wZXJzIHRoYXQgd3JpdGUgYXBwbGlj YXRpb25zKSBvbiBkdWFsLXN0YWNrIG5ldHdvcmtzIHdpdGggYSBtaXggb2YgU0xBQUMgYW5kIERI Q1B2NiB3aWxsIGJlIGFibGUgdG8gbWFrZSBiZXR0ZXIgY2hvaWNlcyBiZXR3ZWVuIHRoZXNlIHBy b3RvY29scyB0aGFuIHdlIGNhbiB0b2RheS4NCg0KQ2hlZXJzLA0KTG9yZW56bw0KDQpPbiBGcmks IEphbiAyMCwgMjAxNyBhdCAxOjU5IEFNLCBCZXJuaWUgVm9seiAodm9seikgPHZvbHpAY2lzY28u Y29tPG1haWx0bzp2b2x6QGNpc2NvLmNvbT4+IHdyb3RlOg0KV2hpbGUgSSBwcm9iYWJseSBzaG91 bGRuJ3Qgc2VuZCB0aGlzIGFzIGl0IGlzIGluIHRoZSBwb2xpdGljYWwgYW5kIG5vdCB0ZWNobmlj YWwgc3BhY2UsIEkgZnJhbmtseSBhbSB2ZXJ5IGRpc2FwcG9pbnRlZCBpbiBvbmUgY29tcGFueSB0 aGF0LCB3aGlsZSB0cnlpbmcgdG8gcHJvbW90ZSBJUHY2IHVzYWdlLCBoYXMgYWxzbyB3b3JrZWQg dmVyeSBoYXJkIHRvIGxpbWl0IGl0cyB1c2UgYnkgTk9UIHN1cHBvcnRpbmcgYSBwcm90b2NvbCBk ZXZlbG9wZWQgYnkgdGhlIElFVEYuDQoNCkknbSBhbHNvIHN1cnByaXNlZCB0aGF0IG9yZ2FuaXph dGlvbnMgaGF2ZW4ndCBwdXNoZWQgaGFyZGVyIHRvIGdldCB0aGF0IGNvbXBhbnkgdG8gaW1wbGVt ZW50IHRoZSBzdGFuZGFyZHMuIEkgc3VzcGVjdCB0aG91Z2ggdGhhdCBpcyBiZWNhdXNlIElQdjYg aXMgbm90IHlldCAiY3JpdGljYWwiIGZvciBkZXBsb3ltZW50LiBUaGlzIHByb3ZpZGVzIHRoZSBj b21wYW55IGFuIG9wcG9ydHVuaXR5IHRvIHB1c2ggdGhlaXIgYWdlbmRhICh3aGF0ZXZlciBpdCBt YXkgYmUpLg0KDQpJIHdpbGwgYWRtaXQgdGhhdCBiZWluZyBESEMgV0cgY28tY2hhaXIsIGNvYXV0 aG9yIG9mIHRoZSBzb21lIG9mIHRoZSBzdGFuZGFyZHMsIGFuZCBhbHNvIGEgdmVuZG9yIGRvZXMg YmlhcyBtZS4NCg0KLSBCZXJuaWUNCg0K --_000_5a275aeadcd943e38d443735acb761a4XCHALN003ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0xpc3RQYXJh Z3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1z dHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0K CW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biIsc2VyaWY7fQ0Kc3Bhbi5ob2VuemINCgl7bXNvLXN0eWxlLW5hbWU6aG9lbnpiO30NCnNwYW4u RW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5IVE1MUHJl Zm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1h dHRlZCI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2lu OjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3Qt aWQ6NDczMDY2NTc0Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRl LWlkczotMTM3Njc1NzI5MCAxMTY3NzQ5ODEwIDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3 Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxl dmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MDsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5 OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxp c3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxl dmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTow aW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYi IC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl bGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0K PC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0i RU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5IaSBMb3JlbnpvOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ SSBkbyByZWdyZXQgbm90IGJlaW5nIG1vcmUgYWN0aXZlIHdoZW4gUkZDIDc5MzQgd2FzIGJlaW5n IGRyYWZ0ZWQgYXMgSSB0aGluayB0aGVyZSBhcmUgc29tZSB0aGluZ3MgYWJvdXQgREhDUHY2IHRo YXQgYXJlIGEgYml0IG9mZi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDtJdCBpcyBh bHNvIHRlY2huaWNhbGx5IHBvc3NpYmxlIGZvciBhIGNsaWVudDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgdG8gcmVxdWVzdCBhZGRpdGlvbmFsIGFkZHJlc3NlcyB1c2lu ZyBhIGRpZmZlcmVudCBESENQIFVuaXF1ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgSWRlbnRpZmllciAoRFVJRCksIHRob3VnaCB0aGUgREhDUHY2IHNwZWNpZmljYXRp b24gaW1wbGllcyB0aGF0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0 aGlzIGlzIG5vdCBleHBlY3RlZCBiZWhhdmlvciAoPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL3JmYzMzMTUjc2VjdGlvbi05Ij5bUkZDMzMxNV0sIFNlY3Rpb24mbmJzcDs5PC9h PikuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoZSB3YXkg YSBjbGllbnQgY2FuIGdldCBtYW55IGFkZHJlc3NlcyBpcyBzaW1wbHkgdG8gc2VuZCBpbiBtdWx0 aXBsZSBJQV9OQSAob3IgSUFfVEEgb3IgSUFfUEQpIG9wdGlvbnMgd2l0aCBkaWZmZXJlbnQgSUFJ RCB2YWx1ZXMuIFRoZXJlIGlzIG5vIG5lZWQgdG8gY2hhbmdlDQogdGhlIERVSUQuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmU+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJm5ic3A7VGhlIG1heGltdW0gbnVtYmVyIG9mIElQdjYgYWRkcmVzc2VzIHRo YXQgY2FuIGJlIHByb3ZpZGVkPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGluIGEgc2lu Z2xlIERIQ1B2NiBwYWNrZXQsIGdpdmVuIGEgdHlwaWNhbCBNVFUgb2YgMTUwMCBieXRlcyBvcjxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzbWFsbGVyLCBpcyBhcHByb3hpbWF0ZWx5IDMw PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkJ1dCBhIGNsaWVu dCBpcyBmcmVlIHRvIHNlbmQgbWFueSBzZXBhcmF0ZSB0cmFuc2FjdGlvbnMgKG11bHRpcGxlIHBh Y2tldHMpLiBGb3IgZXhhbXBsZSwgb25lIGFwcHJvYWNoIHdvdWxkIGJlIHRvIHNlbmQgYSBuZXcg cmVxdWVzdCB3aGVuZXZlciBhIG5ldyBhZGRyZXNzIGlzDQogbmVlZGVkIOKAkyB0aGlzIHdvdWxk IGJlIGFuIElBX05BIChmb3Igbm9uLXRlbXBvcmFyeSBhZGRyZXNzKSB3aXRoIGEgdW5pcXVlIElB SUQuIEFuZCwgdGhhdCBtaWdodCBiZSBtdWNoIGVhc2llciB3aGVuIHlvdSBoYXZlIGR5bmFtaWMg bmVlZHMgKGkuZS4sIGRldmljZSBiZWluZyBhZGRlZCBvdmVyIHRpbWUpLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QW5kLCBlYWNoIHRyYW5zYWN0aW9uIGRvZXMg bm90IG5lZWQgdG8gc3RhcnQgd2l0aCB0aGUgc2VydmVyIGRpc2NvdmVyeSBwcm9jZXNzIHNpbmNl IHRoYXQgaGFzIGFscmVhZHkgYmVlbiBkb25lIOKAkyB0aGV5IGNhbiBzdGFydCB3aXRoIGEgUmVx dWVzdCAoMiBtZXNzYWdlIGV4Y2hhbmdlKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPlNhZGx5LCB3ZSBtYXkgaGF2ZSBtYWRlIHRoaW5ncyBldmVuIGEgYml0IHdv cnNlIHdpdGggdGhlIGludHJvZHVjdGlvbiBvZiBSRkMgNzU1MCBhcyB0aGlzIHByb21vdGVzIHVz aW5nIGEgc2luZ2xlIHRyYW5zYWN0aW9uIHdoZW4gYXNraW5nIGZvciBtdWx0aXBsZSB0aGluZ3MN CiAoSUFfTkEgJiM0MzsgSUFfUEQgaXMgdGhlIGNsYXNzaWMgZXhhbXBsZSkuIEJ1dCB0aGUgZ29h bCBvZiBSRkMgNzU1MCB3YXMgdG8gbWFrZSB0aGUgQ3VzdG9tZXIgRWRnZSAoQ0UpIHJvdXRlciAo ZGVzY3JpYmVkIGluIFJGQzcwODQpIG1vZGVsIHNpbXBsZXIg4oCTIGVzcGVjaWFsbHkgaW4gY2Fz ZXMgd2hlcmUgbm90IGJvdGggYW4gYWRkcmVzcyBhbmQgZGVsZWdhdGVkIHByZWZpeCBtaWdodCBi ZSBhdmFpbGFibGUuIEFuZCwgaWYgZG9lc27igJl0IHByZWNsdWRlZA0KIHRoZSBzZXBhcmF0ZSB0 cmFuc2FjdGlvbiBtb2RlbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5OZWl0aGVyIG9mIHRoZSBzdGF0ZW1lbnRzIGlu IHRoZSBSRkMgaXMgdGVjaG5pY2FsbHkgd3JvbmcgKGFzIGNoYW5naW5nIHRoZSBEVUlEIGlzIGNl cnRhaW5seSBvbmUgd2F5IHRvIGFjY29tcGxpc2ggdGhhdCBnb2FsLCBhbmQgdGhlIGxpbWl0IGZv ciBhIHNpbmdsZSBwYWNrZXQNCiBpcyBjb3JyZWN0KS4gQnV0IGl0IGp1c3QgbGVhdmVzIHRoZSB3 cm9uZyBpbXByZXNzaW9uIGFib3V0IERIQ1B2Ni4gV2UgZGVzaWduZWQgaXQgdG8gYWxsb3cgTE9U UyBvZiBhZGRyZXNzZXMgcGVyIGNsaWVudCBhbmQgYmUgdmVyeSBmbGV4aWJsZSBpbiBob3cgdGhv c2UgYWRkcmVzc2VzIGFyZSDigJxncm91cGVk4oCdIChpLmUuLCBieSBJQV8qIHR5cGUgYW5kIElB SUQpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QW5kLCB5ZXMg dGhpcyBpcyBtb3JlIGNvZGUgYW5kIG92ZXJoZWFkIHRvIGp1c3QgaGF2aW5nIGEgLzY0IGF2YWls YWJsZSBhbmQgYnVpbGRpbmcgYW4gYWRkcmVzcyB3aGVuZXZlciBpdCBpcyBuZWVkZWQgKHRoYXTi gJlzIGEgZmV3IGxpbmVzIG9mIGNvZGUgdG8gd3JpdGUgYW5kDQogZXhlY3V0ZSkg4oCTIG5vIGV4 dHJhIGV4dGVybmFsIGNvbW11bmljYXRpb24gbmVjZXNzYXJ5LjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIg c3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYg IXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxl PSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5CZXJuaWU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gTG9yZW56byBDb2xpdHRpIFttYWls dG86bG9yZW56b0Bnb29nbGUuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBKYW51 YXJ5IDE5LCAyMDE3IDEyOjQzIFBNPGJyPg0KPGI+VG86PC9iPiBCZXJuaWUgVm9seiAodm9seikg Jmx0O3ZvbHpAY2lzY28uY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gQ2h1Y2sgQW5kZXJzb24gJmx0 O2NyYUB3cGkuZWR1Jmd0OzsgRmVybmFuZG8gR29udCAmbHQ7ZmdvbnRAc2k2bmV0d29ya3MuY29t Jmd0OzsgdjZvcHMgbGlzdCAmbHQ7djZvcHNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8 L2I+IFJlOiBbdjZvcHNdIGRyYWZ0LWlldGYtdjZvcHMtZGhjcHY2LXNsYWFjLXByb2JsZW08bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmVybmllLDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5oYXZlIHlvdSBy ZWFkIFJGQyA3OTM0PyBJdCBsaXN0cyBhIG51bWJlciBvZiByZWFzb25zIHdoeSBpdCBpcyBub3Qg cmVjb21tZW5kZWQgZm9yIG5ldHdvcmtzIHRvIHN1cHBvcnQgb25seSBESENQdjYgYWRkcmVzcyBh c3NpZ25tZW50IHZpYSBJQV9OQS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SSBkb24ndCB0aGluayBESENQdjYgaW4gaXRzZWxmIGlzIGEgcHJv YmxlbS4gV2hpbGUgaXQgZG9lcyBzdWZmZXIgZnJvbSB0aGUgbGltaXRhdGlvbnMgSSBvdXRsaW5l ZCBpbiBteSBlYXJsaWVyIG1lc3NhZ2UsIGl0IGlzIGZsZXhpYmxlIGFuZCBleHRlbnNpYmxlIHRv IHdheSBtb3JlIGluZm9ybWF0aW9uIHRoYW4gUkFzIGNhbiBjYXJyeS4gSXQncyBhbHNvIHdpZGVs eSBzdXBwb3J0ZWQuIEJ1dCBJIHJlYWxseQ0KIHRoaW5rIElBX05BIGlzIG5vdCBhcHByb3ByaWF0 ZSBmb3IgSVB2NiBhc3NpZ25tZW50LCBmb3IgdGhlIHJlYXNvbnMgdGhhdCB0aGUgYXV0aG9ycyBh bmQgdGhlIFdHIG91dGxpbmUgaW4gUkZDNzkzNC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VW5mb3J0dW5hdGVseSwgZm9yIG1hbnksIGRlY2Fk ZXMgb2Ygb3BlcmF0aW9uYWwgZmFtaWxpYXJpdHkgYW5kIHZlbmRvciBzdXBwb3J0IHdpdGggSVB2 NCBuZXR3b3Jrcywgd2hlcmUgdGhlIG9ubHkgd2F5IHRvIGdldCBhbiBJUCBhZGRyZXNzIChhbmQg b25seSBldmVyIE9ORSBhZGRyZXNzKSB3YXMgREhDUCwgbWFrZSBpdCB2ZXJ5IGhhcmQgdG8gdGhp bmsgb2YgYW55IG90aGVyIGFkZHJlc3MgYXNzaWdubWVudA0KIG1lY2hhbmlzbS4gU0xBQUMgaXMg cmVndWxhcmx5IGRpc21pc3NlZCBhcyBvdXRsYW5kaXNoIGFuZCBpbnNlY3VyZSwgLzY0IHN1Ym5l dHMgYXMgd2FzdGVmdWwsIGFuZCB0aGUgaW5zaXN0ZW5jZSB0aGF0IElQdjQgYW5kIElQdjYgZGVt YW5kIGRpZmZlcmVudCBsaW5rLWFkZHJlc3NpbmcgcHJhY3RpdmVzIGFzIHJlbGlnaW9uLiAmcXVv dDtXaHkgY2FuJ3Qgd2UganVzdCB1c2UgREhDUCZxdW90OywgYXMgYW4gZWFybGllciBtZXNzYWdl IHB1dCBpdC4gVW5mb3J0dW5hdGVseQ0KIHRoZSB0cnV0aCBpcyBtdWNoIG1vcmUgY29tcGxleCB0 aGFuIHRoYXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPklmIHRoZSBJbnRlcm5ldCBpcyBldmVudHVhbGx5IHRvIHJlYXAgdGhlIGZ1bGwgYmVu ZWZpdHMgb2YgSVB2NiwgdGhlbiB3ZSBhcyBhIHRlY2huaWNhbCBjb21tdW5pdHkgYW5kIGFzIGFu IGluZHVzdHJ5IG5lZWQgdG8gZ2l2ZSBhIGNoYW5jZSB0byBhIG5ldyBhZGRyZXNzaW5nIG1vZGVs IHdoZXJlIGhvc3RzIGNhbiB1c2UgYXMgbWFueSBJUHY2IGFkZHJlc3NlcyBhcyB0aGV5IG5lZWQu IFJpZ2h0IG5vdywgdGhhdA0KIG1lYW5zIFNMQUFDLiBUaGUgZmFjdCBvZiB0aGUgbWF0dGVyIGlz IHRoYXQgaXQgU0xBQUMncyBzZWN1cml0eSBwcm9wZXJ0aWVzIGFyZSBub3Qgc3Vic3RhbnRpYWxs eSB3b3JzZSB0aGFuIElBX05BLCBhbmQgYW55b25lIHdobyBzYXlzIGRpZmZlcmVudGx5IHNob3Vs ZCByZWFkIFJGQyA3OTM0IHNlY3Rpb24gOS4xLCBvZiB3aGljaCBJIGhhdmUgbm90IHlldCBzZWVu IGFueSByZWJ1dHRhbCwgY29udmluY2luZyBvciBvdGhlcndpc2UuIEFuZCBhcw0KIGZvciAvNjRz IGJlaW5nIHdhc3RlZnVsIC0geW91IHNhdyB0aGUgZWFybGllciBtZXNzYWdlcyBpbiB0aGlzIGNv bnZlcnNhdGlvbiB0aGF0IGFzc2VydGVkIHRoYXQgcHJlZml4ZXMgY29zdCBtb25leSBvciB0aGV5 IGFyZSBoYXJkIHRvIG9idGFpbiwgd2hlbiBpbiBmYWN0IHRoZSBjb3N0IGlzIG9yZGVycyBvZiBt YWduaXR1ZGUgbG93ZXIgdGhhbiBvbmUgY2VudCwgYW5kIFJJUiBwb2xpY2llcyBlcmUgZXh0cmVt ZWx5IGxpYmVyYWw/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkl0IHdvdWxkIGJlIGV4dHJlbWVseSBlYXN5IHRvIHNpbXBseSBjYXJyeSBvdmVy IHByYWN0aWNlcyB0aGF0IHdlIGhhdmUgaW4gSVB2NCB0byBJUHY2LiBCdXQgYmVjYXVzZSBhcHBs aWNhdGlvbnMgYXJlIGluY2VudGl2aXplZCB0byBhZGQgYXBwbGljYXRpb24gY29tcGxleGl0eSBp biBvcmRlciB0byB3b3JrIHByb3Blcmx5IG9uIGFsbCBuZXR3b3JrcywgdGhlcmUgaXMgYSByaXNr IHRoYXQgd2UgbWlnaHQgZ2V0DQogc3R1Y2sgdGhlcmUsIGFuZCBuZXZlciBiZSBhYmxlIHRvIGVs ZXZhdGUgb3Vyc2VsdmVzIG91dCBvZiB0aG9zZSBwcmFjdGljZXMuIElmIHRoYXQgaGFwcGVucyB3 aWxsIGtlZXAgc3VmZmVyaW5nIHRoZSBwcm9ibGVtcyBjYXVzZWQgYnkgSVAgYWRkcmVzcyBzY2Fy Y2l0eSBldmVuIGFmdGVyIHNjYXJjaXR5IGlzIGJhbmlzaGVkLiBUaGF0IHdvdWxkIGJlIGEgYmFk IG91dGNvbWUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk9mIGNvdXJzZSBJIG1heSBiZSB3cm9uZyBhbmQgYSBvbmUtYWRkcmVzcy1wZXItaG9z dCBtb2RlbCBpcyB0aGUgcmlnaHQgY2hvaWNlLiBCdXQgSSBkb24ndCB0aGluayB3ZSBjYW4gdGVs bCBhdCB0aGUgbW9tZW50LiBPdmVyIHRoZSB5ZWFycywgbmV0d29yayBhZG1pbmlzdHJhdG9ycyB0 aGF0IGxlYXJuIGFib3V0IElQIChhbmQgYXBwbGljYXRpb24gZGV2ZWxvcGVycyB0aGF0IHdyaXRl IGFwcGxpY2F0aW9ucykNCiBvbiBkdWFsLXN0YWNrIG5ldHdvcmtzIHdpdGggYSBtaXggb2YgU0xB QUMgYW5kIERIQ1B2NiB3aWxsIGJlIGFibGUgdG8gbWFrZSBiZXR0ZXIgY2hvaWNlcyBiZXR3ZWVu IHRoZXNlIHByb3RvY29scyB0aGFuIHdlIGNhbiB0b2RheS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TG9yZW56bzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGcmksIEphbiAyMCwg MjAxNyBhdCAxOjU5IEFNLCBCZXJuaWUgVm9seiAodm9seikgJmx0OzxhIGhyZWY9Im1haWx0bzp2 b2x6QGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnZvbHpAY2lzY28uY29tPC9hPiZndDsgd3Jv dGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5XaGlsZSBJIHByb2JhYmx5IHNob3VsZG4ndCBzZW5k IHRoaXMgYXMgaXQgaXMgaW4gdGhlIHBvbGl0aWNhbCBhbmQgbm90IHRlY2huaWNhbCBzcGFjZSwg SSBmcmFua2x5IGFtIHZlcnkgZGlzYXBwb2ludGVkIGluIG9uZSBjb21wYW55IHRoYXQsIHdoaWxl IHRyeWluZyB0byBwcm9tb3RlIElQdjYgdXNhZ2UsIGhhcyBhbHNvIHdvcmtlZCB2ZXJ5IGhhcmQg dG8gbGltaXQNCiBpdHMgdXNlIGJ5IE5PVCBzdXBwb3J0aW5nIGEgcHJvdG9jb2wgZGV2ZWxvcGVk IGJ5IHRoZSBJRVRGLjxicj4NCjxicj4NCkknbSBhbHNvIHN1cnByaXNlZCB0aGF0IG9yZ2FuaXph dGlvbnMgaGF2ZW4ndCBwdXNoZWQgaGFyZGVyIHRvIGdldCB0aGF0IGNvbXBhbnkgdG8gaW1wbGVt ZW50IHRoZSBzdGFuZGFyZHMuIEkgc3VzcGVjdCB0aG91Z2ggdGhhdCBpcyBiZWNhdXNlIElQdjYg aXMgbm90IHlldCAmcXVvdDtjcml0aWNhbCZxdW90OyBmb3IgZGVwbG95bWVudC4gVGhpcyBwcm92 aWRlcyB0aGUgY29tcGFueSBhbiBvcHBvcnR1bml0eSB0byBwdXNoIHRoZWlyIGFnZW5kYSAod2hh dGV2ZXIgaXQNCiBtYXkgYmUpLjxicj4NCjxicj4NCkkgd2lsbCBhZG1pdCB0aGF0IGJlaW5nIERI QyBXRyBjby1jaGFpciwgY29hdXRob3Igb2YgdGhlIHNvbWUgb2YgdGhlIHN0YW5kYXJkcywgYW5k IGFsc28gYSB2ZW5kb3IgZG9lcyBiaWFzIG1lLjxicj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojODg4 ODg4Ij48YnI+DQo8c3BhbiBjbGFzcz0iaG9lbnpiIj4tIEJlcm5pZTwvc3Bhbj48L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_5a275aeadcd943e38d443735acb761a4XCHALN003ciscocom_-- From nobody Thu Jan 19 15:29:41 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5956129421 for ; Thu, 19 Jan 2017 15:29:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=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 u1beWQwfO_UG for ; Thu, 19 Jan 2017 15:29:37 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 5E7891293D6 for ; Thu, 19 Jan 2017 15:29:37 -0800 (PST) Received: from stereo.hq.phicoh.net ([::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #127) id m1cUM99-0000EPC; Fri, 20 Jan 2017 00:29:35 +0100 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bF054DD66@u-1.phicoh.com References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <99204933-5CB6-4E89-BD6A-FD40136DF6F5@steffann.nl> In-reply-to: Your message of "Thu, 19 Jan 2017 16:09:22 -0500 ." Date: Fri, 20 Jan 2017 00:29:34 +0100 Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 23:29:40 -0000 >On Jan 19, 2017, at 3:12 PM, Mark Smith wrote: >> I'd say many of the DHCPv6 options do - I think only IA_NA and IA_TA >> are the only exceptions. > >Providing the IP address of a recursive resolver isn't so bad, because you hav >e DNSSEC to protect you. I'd say, for the general mobile case, like connecting to the wireless network at Starbucks, any protocol that doesn't provide both encryption and authenticated data is just a security accident waiting to happen. For DNS, we have authentication, if you do local DNSSEC validation. If you rely on Google's public DNS resolver to do DNSSEC validation then you are completely exposed. To also do encryption, you need something like TLS to your DNS resolver. (Of course pinning the certificate you accept). >> So what is the alternative? > >For NTP, you should probably be using the NTP server your vendor configured, u >nless you have your own, in which case you should be using that. For SMTP, y >ou should be using the SMTP server your email provider offers, not the one the > network offers. For print, you should probably be using DNSSD, not DHCP. >Etc. You should have an authenticated trust relationship with any service yo >u use, so that you can tell if you are being spoofed. By and large NTP is used without authentication. So it doesn't matter which NTP server you want to talk to, your wireless connection can spoof the replies anyhow. So do you really want to decide whether a certificate is expired or not based on time that can be spoofed by your local wifi network? For SMTP you want a TLS connection to a configured DNS name. So that can be secured. I doubt that printing on the go can secured. So print only stuff that can be made public anyhow. Where it gets interesting, if you connect using 802.1X to your corporate wifi, then you really want to trust (and use) what you get from DHCP because it makes life a lot easier and the firewall may block everything else. From nobody Thu Jan 19 15:50:17 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4596C1296BA for ; Thu, 19 Jan 2017 15:50:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 QbzJlgBuULNR for ; Thu, 19 Jan 2017 15:50:15 -0800 (PST) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CAB41296B8 for ; Thu, 19 Jan 2017 15:50:15 -0800 (PST) Received: by mail-pg0-x22e.google.com with SMTP id 194so17995883pgd.2 for ; Thu, 19 Jan 2017 15:50:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:message-id:mime-version:subject:date:references:to:in-reply-to; bh=gAtZlpI9uWiwP2UcGfKmY/bgOrm8lmPSiitmnzUlBzU=; b=XpxzVv+kAITthkHLeTHIVXjWfKnoXw+WxbzPRtxCGqV9YPv26s7LTPy4HIxzs+Jz1Q 83OANgUCoRaDVO4YhPkH6vHkH577Sr7Ufzcj2R4YCELhMuV/laW9AxEfbN0+2MVrIQW6 us5s26vP48VSVgwIAFMow0e/sM9p1s10dfQUTsMjGe2icP9LQCjMDcgcO9/RXMMl36k+ MC8AqnZlwSXONoANMMLZ9evads2NrvJREi9J3YzG7vgwqsbE1ITl7PRIBDn54goVA0VI MIBsVnJqjPEydmpl1+o9BuJods7ETj58gQmo5UIzJYQK/8yg/omFp6yUbWaftHMmccLe mkAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :references:to:in-reply-to; bh=gAtZlpI9uWiwP2UcGfKmY/bgOrm8lmPSiitmnzUlBzU=; b=DQUMZlAbE3Gv7EtrYyPcU8sf/G6gSJik2nGEgVchA59RJjXdwtXrD3OuW1YxWx6HwP ZjG2fhYPP+Q/mHsGPG/Gi5tOoRKnN+HU+Chi4c+R5UJJeQKw3UVi7ydZxVuQoHTo59Cm mnGXfzw80LLR2shMPTzOF6EQQrCbH+dYDYgBeDAVMyW1dmP05riomwuJm67LnVApKjvm zol8m5orVf9NFkiGCYuJB9H3wDfwJvvVDUva951M/jp77adliZsExwhs+CV1+G0ssUVF Mtp99BJjQi0Kk5kb/7NE9hpCiX7pD1AucFCV/FRX9WPIekzTr/Lni+AggM4a9MprEJVu V1Cw== X-Gm-Message-State: AIkVDXICOgvqSc0d4JPtfTEWb/ozGYvWQJDt0enTsI2+tf+ibXyI9flmLsmdflPC4jTLnBUp X-Received: by 10.84.150.129 with SMTP id h1mr17159789plh.9.1484869814375; Thu, 19 Jan 2017 15:50:14 -0800 (PST) Received: from ?IPv6:2001:5a8:4:2290:958d:fc76:26f:3d1c? ([2001:5a8:4:2290:958d:fc76:26f:3d1c]) by smtp.gmail.com with ESMTPSA id p26sm11407665pfj.23.2017.01.19.15.50.13 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 19 Jan 2017 15:50:13 -0800 (PST) From: james woodyatt Content-Type: multipart/alternative; boundary="Apple-Mail=_6689D542-E4F1-4428-B956-6F3E5F0E162F" Message-Id: <207A1D5B-4FF6-4E50-B6D0-4EF7DD6AB9A1@google.com> Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Date: Thu, 19 Jan 2017 15:50:24 -0800 References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <99204933-5CB6-4E89-BD6A-FD40136DF6F5@steffann.nl> To: IPv6 Ops WG In-Reply-To: X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 23:50:16 -0000 --Apple-Mail=_6689D542-E4F1-4428-B956-6F3E5F0E162F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jan 19, 2017, at 11:43, Mark Smith wrote: >=20 > [=E2=80=A6] stateless DHCPv6 is quite simple, and we now we have = confusion about whether to deploy RDNSS or stateless DHCPv6 [=E2=80=A6] I would argue that's because Stateless DHCPv6 is not a very good idea. I = believe its sunset should have begun years ago when DNS-SD was = standardized. Why am I not a fan of Stateless DHCPv6? Because there isn=E2=80=99t a = way for the service advertiser to update or delete a service location = previously provided to hosts except to let its timer expire. For that, = you need to use DNS-SD. I believe there are no good reasons to deploy = Stateless DHCPv6 except to support legacy devices that A) have not yet = adopted DNS-SD as the standard for service discovery, and B) have not = yet adopted RDNSS as the standard for DNS configuration discovery. --james woodyatt > --Apple-Mail=_6689D542-E4F1-4428-B956-6F3E5F0E162F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Jan 19, 2017, at 11:43, Mark Smith <markzzzsmith@gmail.com> wrote:

[=E2=80=A6] stateless DHCPv6 is quite simple, = and we now we have confusion about = whether to deploy RDNSS or stateless DHCPv6 = [=E2=80=A6]

I would argue that's because Stateless = DHCPv6 is not a very good idea. I believe its sunset should have begun = years ago when DNS-SD was standardized.

Why am I not a fan of Stateless DHCPv6? = Because there isn=E2=80=99t a way for the service advertiser to update = or delete a service location previously provided to hosts except to let = its timer expire. For that, you need to use DNS-SD. I believe there are = no good reasons to deploy Stateless DHCPv6 except to support legacy = devices that A) have not yet adopted DNS-SD as the standard for service = discovery, and B) have not yet adopted RDNSS as the standard for DNS = configuration discovery.


--james woodyatt <jhw@google.com>



= --Apple-Mail=_6689D542-E4F1-4428-B956-6F3E5F0E162F-- From nobody Thu Jan 19 16:00:15 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E5FC1296B3 for ; Thu, 19 Jan 2017 16:00:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 M8qelykZ7SzB for ; Thu, 19 Jan 2017 16:00:12 -0800 (PST) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7299C1295C4 for ; Thu, 19 Jan 2017 16:00:12 -0800 (PST) Received: by mail-yw0-x233.google.com with SMTP id w75so56482676ywg.1 for ; Thu, 19 Jan 2017 16:00:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=pYzF6iYxrOdkIqZeKXLXwNWCvDY+rjD7fpwToKfm8wo=; b=LOdxOzY4PDnVmnBtS8u2aG9S/XlRDekXBKc17QoOZgwbJwQZP61Pif5uHV/iPNtjRK rjYH8Y+eZpD0J0SsySqDn7TA0bDrTfvSXMxUL2VE4aGs3sQbHmPH9IRo3RwfNG50hsCH 0c3wBUjIPUQ0UZC9KlYibfDxQk6dj/7uI2wnVYOBvJRq5WmJERhOjRe1W9kRqFwu5Lp9 N8N2xOZGNn2dciSHN0589AA3tAM+5rJ82Tqkx9lh0ixZugRkXbppCwjeAbwC/vaxEAsk qkH/zEWpnPs7HIFl96A0G1+mZy7cPbN01MkN533bEPw0BHxBaaX8BdgcS4+QvCiN+Etp FNlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=pYzF6iYxrOdkIqZeKXLXwNWCvDY+rjD7fpwToKfm8wo=; b=QYerSTRMVp/lTUPyVbs/uedYUJlTS9BfIOu1xuMxYe7ZRpU2+WLRCbvaNIsalGGZQn zY4ELBoBYe5KjaE/e4PodkkuzEsovi0WAoB6zaS/B58Mx7knQHQnfChCJBvgGPj9biYV bmE1PFRisNbayo6B5vUC8bd+x6nDiQ+8U5CM0AenvULNnXHXHQqRnATAH/UMq057XcLs QE/RyUkB1v/Ux/exqlVepngx+bapzbTAttyCYTMxkoS47V4acHGtU8rl8kDVjWdgUeFj LcZjcizJU761YhXo0Mp7AFDGai8DOIaASVhRbWonbTZeKx0a7Yh3nb0ODIi5UXwBB07q +Q1w== X-Gm-Message-State: AIkVDXIc9Gq9mrQrBnKOg9BkacyyiMaxRyl1KQE2V04uaRwSDdVZJmBrn4X/HFpayo6kgw== X-Received: by 10.55.189.70 with SMTP id n67mr10151399qkf.204.1484870411433; Thu, 19 Jan 2017 16:00:11 -0800 (PST) Received: from [192.168.1.228] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id e33sm4418368qtb.31.2017.01.19.16.00.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Jan 2017 16:00:09 -0800 (PST) From: Ted Lemon Message-Id: <3503B63B-DF22-4C54-9548-DDB44A638C22@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_FF09B360-72FB-4E4B-9567-8132610930B0" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Thu, 19 Jan 2017 19:00:08 -0500 In-Reply-To: To: Philip Homburg References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <99204933-5CB6-4E89-BD6A-FD40136DF6F5@steffann.nl> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 00:00:14 -0000 --Apple-Mail=_FF09B360-72FB-4E4B-9567-8132610930B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jan 19, 2017, at 6:29 PM, Philip Homburg = wrote: > Where it gets interesting, if you connect using 802.1X to your = corporate > wifi, then you really want to trust (and use) what you get from DHCP = because > it makes life a lot easier and the firewall may block everything else. Perhaps so, but how does your device know to differentiate between this = case and other cases? Also, if it is your personal device that you have brought in to work, do = you necessarily want to accept everything that your work DHCP server = tells your device? BTW, I was kidding about DNSSEC. Right now you don't get any = validation, because nothing you're using is signed. And you should be = using ntp with some kind of signing, even if it's shared private key. = Apple doesn't appear to do that, which I guess isn't shocking (that's my = test case=E2=80=94I don't know what other software is doing). But the = fact that this isn't being properly secured is not a reason to do = something dumb security-wise at the lower layer. Hopefully at some = point this problem will be fixed, and we shouldn't make fixing it = harder. That's the deal with DNSSEC as well=E2=80=94even though it isn't broadly = deployed _now_, it will be when it starts to become obvious that it = should be. But the signing infrastructure for DNSSEC allows for the = DNS distributed caching system to work and be secured, whereas existing = NTP authentication does not, and it's unlikely that that will change. = So distributing DNS resolver info with ND and DHCP doesn't create an = additional security exposure; distributing NTP does.= --Apple-Mail=_FF09B360-72FB-4E4B-9567-8132610930B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Jan 19, 2017, at 6:29 PM, Philip Homburg <pch-v6ops-6@u-1.phicoh.com> wrote:
Where it gets = interesting, if you connect using 802.1X to your corporate
wifi, then you really want to trust (and use) = what you get from DHCP because
it makes life a lot easier and = the firewall may block everything = else.

Perhaps so, but how does your device know to differentiate = between this case and other cases?

Also, if it is your personal device = that you have brought in to work, do you necessarily want to accept = everything that your work DHCP server tells your device?

BTW, I was kidding about = DNSSEC.   Right now you don't get any validation, because nothing = you're using is signed.   And you should be using ntp with some = kind of signing, even if it's shared private key.   Apple doesn't = appear to do that, which I guess isn't shocking (that's my test case=E2=80= =94I don't know what other software is doing).   But the fact that = this isn't being properly secured is not a reason to do something dumb = security-wise at the lower layer.   Hopefully at some point this = problem will be fixed, and we shouldn't make fixing it harder.

That's the deal with = DNSSEC as well=E2=80=94even though it isn't broadly deployed _now_, it = will be when it starts to become obvious that it should be.   But = the signing infrastructure for DNSSEC allows for the DNS distributed = caching system to work and be secured, whereas existing NTP = authentication does not, and it's unlikely that that will change.   = So distributing DNS resolver info with ND and DHCP doesn't create an = additional security exposure; distributing NTP does.
= --Apple-Mail=_FF09B360-72FB-4E4B-9567-8132610930B0-- From nobody Thu Jan 19 16:03:00 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B8F71295CA for ; Thu, 19 Jan 2017 16:02:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 8iXdGTiOwDvG for ; Thu, 19 Jan 2017 16:02:57 -0800 (PST) Received: from mail-yb0-x233.google.com (mail-yb0-x233.google.com [IPv6:2607:f8b0:4002:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0BAA1295C4 for ; Thu, 19 Jan 2017 16:02:56 -0800 (PST) Received: by mail-yb0-x233.google.com with SMTP id j82so40557025ybg.1 for ; Thu, 19 Jan 2017 16:02:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=7qthnkc+efIb5k5Ul/WIkzev8kPdrDBmUBe6xgMcths=; b=AoUJwdUZ47I0SnrcDkpWPVm5tKmDT+qNSdo6uQM/YLw+VebAPWSigUwgKH+ynC72S7 Wmsmp5jSe4jqigRQHfIY/ApfUSi1oQQgZcUZXSkZ65k/Vqcd0GLFouRpJ11w2yBUtW9B TM2CknECLFxWnmTu+NYqWOXfRHmI72MZlDvNENkwNu+4hNZbAxKYVbEUJmeibTG3rnUH cQAgSlZclr7WVr6zE4JkdVAPM5ILpe3znR/RLkBmlXhYibgmpCdthiCJvBPdHLCXe36E lBPxp1y7pkNNF6kCA8+s9VNqQxV0XU7+WzyGckOwY4EqTzhcHhhJ1Rz1mh0lu2VEQFh6 48QQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=7qthnkc+efIb5k5Ul/WIkzev8kPdrDBmUBe6xgMcths=; b=PQYe6uqyvt3FtER0x46FWL4T2Id9dEi3Kzc1vC7nk2GmCkKfG0aHS6BN9/BrhnRZo6 LxYKRuRj/72eBNSQi6QsWjHF4SH5Pi6iEaOjfsCT6ZV7QcmPFNDq3iYU2n+t8FRgmwfM ztVvnuXn34jKSoYY6inrlAjgohkpfuXaiMsEwWWjOeiHZ7+05+q4Hd0d7OxW68JB+dxW grddpKP438nj6JoEi7nGJ4lFvVTEM+EXI6LesVjSF1yE1aGV24DHFcH+WgwrCje6ikoX QXXiKLCMFfOVVHl7RDSF8RCjQi6zsxmdeW19Tn4wGbOwUYN+x0KnLJRn89HBuui4NGzP nK/g== X-Gm-Message-State: AIkVDXI0wPH6GrnKMDLF37dg7bpHKFwr4WST0dX7dMYkA5FSlTX3O6HZdC34zbcm4lYsvw== X-Received: by 10.237.42.1 with SMTP id c1mr9661558qtd.10.1484870576177; Thu, 19 Jan 2017 16:02:56 -0800 (PST) Received: from [192.168.1.228] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id b36sm4455391qte.21.2017.01.19.16.02.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Jan 2017 16:02:54 -0800 (PST) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_09259745-C2B0-43A4-B420-816EC688C065" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Thu, 19 Jan 2017 19:02:53 -0500 In-Reply-To: <207A1D5B-4FF6-4E50-B6D0-4EF7DD6AB9A1@google.com> To: james woodyatt References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <99204933-5CB6-4E89-BD6A-FD40136DF6F5@steffann.nl> <207A1D5B-4FF6-4E50-B6D0-4EF7DD6AB9A1@google.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 00:02:58 -0000 --Apple-Mail=_09259745-C2B0-43A4-B420-816EC688C065 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jan 19, 2017, at 6:50 PM, james woodyatt wrote: > Why am I not a fan of Stateless DHCPv6? Because there isn=E2=80=99t a = way for the service advertiser to update or delete a service location = previously provided to hosts except to let its timer expire. For that, = you need to use DNS-SD.=20 Hm, you mean with open-ended queries (LLQ)? Does this really make a = difference in practice? I don't think the plumbing is in place to take = advantage of this for the kinds of services that are distributed via = stateless DHCP=E2=80=94that's one of the reasons that there's not been a = stronger push to support DHCPv6 reconfigure for information requests. --Apple-Mail=_09259745-C2B0-43A4-B420-816EC688C065 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Jan 19, 2017, at 6:50 PM, james woodyatt <jhw@google.com> = wrote:
Why am I not a fan of Stateless DHCPv6? Because = there isn=E2=80=99t a way for the service advertiser to update or delete = a service location previously provided to hosts except to let its timer = expire. For that, you need to use DNS-SD. 

Hm, you mean with open-ended queries = (LLQ)?   Does this really make a difference in practice?   I = don't think the plumbing is in place to take advantage of this for the = kinds of services that are distributed via stateless DHCP=E2=80=94that's = one of the reasons that there's not been a stronger push to support = DHCPv6 reconfigure for information requests.

= --Apple-Mail=_09259745-C2B0-43A4-B420-816EC688C065-- From nobody Thu Jan 19 16:22:16 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B2E01295E2 for ; Thu, 19 Jan 2017 16:22:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 JyLFOFJI2yCX for ; Thu, 19 Jan 2017 16:22:12 -0800 (PST) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A0ED128AB0 for ; Thu, 19 Jan 2017 16:22:12 -0800 (PST) Received: by mail-pf0-x232.google.com with SMTP id e4so17338520pfg.1 for ; Thu, 19 Jan 2017 16:22:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:message-id:mime-version:subject:date:references:to:in-reply-to; bh=xDyneNUZroLSp18RRHbDTYvMSHoxrBqwIopB9KC1ayU=; b=CJIJiwFOHA5gYV/zGQquUcrAB3CrGgIhPeCH0eiLhKwcro2IqZCF0oBYMdKntgmYeW 4usUeFsCFLhfa17gH/rLDOsjeDUoC+qA7W5tlDZBeUpM0phjnwFEU7u83F/bMjuSxAfL nIocX02QPm1MFwmNJR096rEfNOUVgeLQomPbKt3YM1HTtDz6TJhMwj1plzuKBrOH2RwF whvF25P418xd5HVNilAs1+dnalOFNwE5kH3MTiOrb9nHRemTn65mvibKRralWc9eDcI8 wTChljUiuyVXG5E6giom8kgsHBGjDmglsFE4sh9MdTdKv5sTKzb+5InqrWJkqfWrxrIJ zUHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :references:to:in-reply-to; bh=xDyneNUZroLSp18RRHbDTYvMSHoxrBqwIopB9KC1ayU=; b=k6lOveJU3GL3AvKcr5eui8l2VXryFmplTa3mOh3EninIVkhkPS24WjJ7ZdpKmDOuPW 6/i7ADsBof7/bUjE3y33U0wt42epM/oDVYU7S/9PXmQktKGNx64NGgmhplcaw01xJz6e mhE0q3w2FxM8yVywm7SP6CuVSLMywwny1bC4Y7XjCcDxiNHCc/zSC7bm50h15kU4qM5i ps+2uRc3mW0MR0W/PHgIwOTUoIQLT++4iOeuLIaBB3nCxVVrlBdWXHjEDHevxd5Ja/e3 3nAij2uP6ypyd89Z6WbLEZqkZMbXml4lv/iRmMB3NAqU21FCCA1QEcF7GSkybkmPvG95 A7MQ== X-Gm-Message-State: AIkVDXKOaO837YOCYKhJ26WDMRe3gYJ6bvlkOzutPaoPn4LsOXp9qINXGyhrlSsdG1oV8nvs X-Received: by 10.99.228.69 with SMTP id i5mr13378409pgk.63.1484871731816; Thu, 19 Jan 2017 16:22:11 -0800 (PST) Received: from ?IPv6:2001:5a8:4:2290:958d:fc76:26f:3d1c? ([2001:5a8:4:2290:958d:fc76:26f:3d1c]) by smtp.gmail.com with ESMTPSA id x81sm11391397pff.69.2017.01.19.16.22.10 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 19 Jan 2017 16:22:11 -0800 (PST) From: james woodyatt Content-Type: multipart/alternative; boundary="Apple-Mail=_6BF866F7-BEF1-4BD3-867E-0CFB4615665D" Message-Id: <142D26B7-D560-46C8-96BD-EE42DBD84183@google.com> Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Date: Thu, 19 Jan 2017 16:22:10 -0800 References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <99204933-5CB6-4E89-BD6A-FD40136DF6F5@steffann.nl> <207A1D5B-4FF6-4E50-B6D0-4EF7DD6AB9A1@google.com> To: IPv6 Ops WG In-Reply-To: X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 00:22:14 -0000 --Apple-Mail=_6BF866F7-BEF1-4BD3-867E-0CFB4615665D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jan 19, 2017, at 16:02, Ted Lemon wrote: > On Jan 19, 2017, at 6:50 PM, james woodyatt > wrote: >> Why am I not a fan of Stateless DHCPv6? Because there isn=E2=80=99t a = way for the service advertiser to update or delete a service location = previously provided to hosts except to let its timer expire. For that, = you need to use DNS-SD.=20 >=20 > Hm, you mean with open-ended queries (LLQ)? It=E2=80=99s called DNS Push Notification now. = > Does this really make a difference in practice? Yes, it makes a big difference, as can be seen, in practice, using the = widely available implementation described by RFC 6281. > I don't think the plumbing is in place to take advantage of this for = the kinds of services that are distributed via stateless DHCP=E2=80=94that= 's one of the reasons that there's not been a stronger push to support = DHCPv6 reconfigure for information requests. I smell a logical circle in there: there hasn=E2=80=99t been a stronger = push to support DHCPv6 Reconfigure in information requests because the = kinds of services that are distributed via Stateless DHCP are not the = sort that have the plumbing available to use it, and there hasn=E2=80=99t = been a stronger push to make more kinds of services distributed via = Stateless DHCP because there isn=E2=80=99t support for DHCPv6 = Reconfigure in information requests. --james woodyatt > --Apple-Mail=_6BF866F7-BEF1-4BD3-867E-0CFB4615665D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Jan 19, 2017, at 16:02, Ted Lemon <mellon@fugue.com> = wrote:
On Jan 19, = 2017, at 6:50 PM, james woodyatt <jhw@google.com> wrote:
Why am I not a fan = of Stateless DHCPv6? Because there isn=E2=80=99t a way for the service = advertiser to update or delete a service location previously provided to = hosts except to let its timer expire. For that, you need to use = DNS-SD. 

Hm, you mean with open-ended queries = (LLQ)?

It=E2=80=99= s called DNS Push Notification now. <https://tools.ietf.org/html/draft-ietf-dnssd-push>
=

Does this really make a difference in = practice?

Yes, = it makes a big difference, as can be seen, in practice, using the widely = available implementation described by RFC 6281.

I = don't think the plumbing is in place to take advantage of this for the = kinds of services that are distributed via stateless DHCP=E2=80=94that's = one of the reasons that there's not been a stronger push to support = DHCPv6 reconfigure for information = requests.

I smell a logical circle in there: there hasn=E2=80=99t been = a stronger push to support DHCPv6 Reconfigure in information requests = because the kinds of services that are distributed via Stateless DHCP = are not the sort that have the plumbing available to use it, and there = hasn=E2=80=99t been a stronger push to make more kinds of services = distributed via Stateless DHCP because there isn=E2=80=99t support for = DHCPv6 Reconfigure in information requests.


--james woodyatt <jhw@google.com>



= --Apple-Mail=_6BF866F7-BEF1-4BD3-867E-0CFB4615665D-- From nobody Thu Jan 19 16:31:56 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 114E01295E2 for ; Thu, 19 Jan 2017 16:31:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 vbOKHhSSylHx for ; Thu, 19 Jan 2017 16:31:53 -0800 (PST) Received: from mail-oi0-x243.google.com (mail-oi0-x243.google.com [IPv6:2607:f8b0:4003:c06::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61F7C129417 for ; Thu, 19 Jan 2017 16:31:53 -0800 (PST) Received: by mail-oi0-x243.google.com with SMTP id u143so4434461oif.3 for ; Thu, 19 Jan 2017 16:31:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QJlbP/7NsyqsbR/2/oqNO+MkzSb8+8ZOu2jLVA80q7o=; b=HYele+7lQQxeXrl2o3mrvijcpF9mZ7YSz9q3/qdssG8rAmkwiErFLkCZf/wQTtmPMv +hzZuDufms85Xjvm4TPOJ573+5gRszvD/hiahMyux5rrrTxAtWl+XrsDTzhy1UoIIS55 LUxj6ZkXvaDz/IZa9VtdpKyDcmzPEybTJkQt6f4nDBQVeVXmYTnbroZqmo99ZHhfe6G/ UX/l0NMRiaIezOsP/N2w5rYrnZdhz/5E2hN2JQ+xn+GzCVSc+J/Jl2x0JwIAT8+qBCno cvffTBXhPi/70/6KObYRGtg6xeqLXxwLvpOe4enpJGV8IsH3YiMdMJWtSU5nB5mGEo7O yNtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QJlbP/7NsyqsbR/2/oqNO+MkzSb8+8ZOu2jLVA80q7o=; b=XhDRsHiP9DBPEh/X3d61IxSZYyZ+37PhrQnsWrAWonTN49MGa5EIhm8h01q3ZpP4Se cFgDi95dsJaA2ghRKnGJuxzKheHFAzG5wjKCmAr4TYT8UDnUF2X+VyvxMAuSBGd2vc/f Q0y4C0t9CE69NI5n31457kUfKdroJ/zsFQOiOlXGNGYUeGU7gibkCDAcZYZVlt7lXSev 3zMnsh2xO3SSBjmtXhqQveOWUmf4s8nvI13te6WOqtd80YujgKo196uDkkW7xE8VOGqL roWQTJV4weWW/CF/ta0BX1mpWDE/rmRe29HPIq3lOVbXnaXOHwUyF90udb0wowDSh3BL h6cQ== X-Gm-Message-State: AIkVDXI1mougxg0O+VxhQsrHW9tkGZVepiJE7LCDX5vgFXcaSegfu3NV/7+DKVcdd5i9yEpJJixgmQuTAeGMuA== X-Received: by 10.202.8.197 with SMTP id 188mr6053953oii.22.1484872312729; Thu, 19 Jan 2017 16:31:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.227.102 with HTTP; Thu, 19 Jan 2017 16:31:52 -0800 (PST) In-Reply-To: <713bae8b-2b00-e94f-9d2c-a609dd154dde@isi.edu> References: <6b761ce0-acb6-8e16-45c5-07fa9fa2f620@isi.edu> <713bae8b-2b00-e94f-9d2c-a609dd154dde@isi.edu> From: Hemant Singh Date: Thu, 19 Jan 2017 19:31:52 -0500 Message-ID: To: Joe Touch Content-Type: multipart/alternative; boundary=94eb2c130572bcb79905467bc613 Archived-At: Cc: v6ops list Subject: Re: [v6ops] TCP related attacks/RFC3128 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 00:31:55 -0000 --94eb2c130572bcb79905467bc613 Content-Type: text/plain; charset=UTF-8 Hi Joe, Sounds reasonable to me. I agree with your firewall comments as well. Thanks, Hemant On Wed, Jan 18, 2017 at 7:44 PM, Joe Touch wrote: > Hi, Hemant, > > It's useful to note that the attack isn't based solely on minimum packet > size; it depends on how duplicate and overlapping fragment are handled as > well. > > The best approach for a firewall is to reassemble such packets. If it > implements an ACL, it's acting like an end host in peeking into the > payload; there's no meaningful or safe way to do so when fragmentation > occurs other than reassembly, IMO. > > Joe > > On 1/18/2017 4:14 PM, Hemant Singh wrote: > > Hi Joe, > > > On Tue, Jan 17, 2017 at 11:56 AM, Joe Touch wrote: > > If you're talking about fragments, then you need to describe the case >> more clearly. IMO, a firewall always needs to reassemble fragments. >> >> Yes, it's an attack using fragments. An ACL is configured on the > router to allows telnet and ssh only from certain source IP addresses. An > attacker uses a source IP port that does not match any source in the ACL. > However, the router has a incorrect implementation for ACLs (or ACL rules > is mis-configured) which processes fragmented packets first before matching > source IP. Once the first fragment is allowed, the subsequent fragments > are let through. The source IP is checked later in the implementation and > thus the hacker gets into the network. An authentication server serving > the router is the last defense against such a hack because a login and > password is required. > >> >> Remember that an IPv4 packet with DF=0 can be fragmented anywhere in the >> network and both IPv4 and IPv6 can be fragmented at the source. >> >> IPv4 requires that a 68 byte packet can traverse the net without >> fragmentation but there are no rules that prohibit smaller packets or >> fragments. E.g., if you are sending a 100-byte packet and it needs to be >> fragmented down to 68 bytes, it's entirely valid to make the first fragment >> as 32 bytes. Anything longer than the IP header ought is defined as valid. >> >> When I get the time, I will check the Linux code and see if it has > anything hard coded for minimum IPv4 packet size. Thanks for your other > replies - make total sense. I am all set. > > Best Regards, > > Hemant > >> >> > > --94eb2c130572bcb79905467bc613 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Joe,

Sounds reasonable to me.=C2=A0 = I agree with your firewall comments as well.

Thank= s,

Hemant


On Wed, Jan 18, 2017 at 7:44 PM= , Joe Touch <touch@isi.edu> wrote:
=20 =20 =20

Hi, Hemant,

It's useful to note that the attack isn't based solely on mi= nimum packet size; it depends on how duplicate and overlapping fragment are handled as well.

The best approach for a firewall is to reassemble such packets. If it implements an ACL, it's acting like an end host in peeking into the payload; there's no meaningful or safe way to do so when fragmentation occurs other than reassembly, IMO.

Joe


On 1/18/2017 4:14 P= M, Hemant Singh wrote:
Hi Joe,


On Tue, Jan 17, 2017 at 11:56 AM, Joe Touch <touch@isi.edu> wrote:

If you're ta= lking about fragments, then=C2=A0 you need to describe the case more clearly. IMO, a firewall always needs to reassemble fragments.

<hs> Yes, it's an attack using fragments.=C2= =A0 An ACL is configured on the router to allows telnet and ssh only from certain source IP addresses.=C2=A0 An attacker us= es a source IP port that does not match any source in the ACL.=C2=A0 However, the router has a incorrect implementati= on for ACLs (or ACL rules is mis-configured) which processes fragmented packets first before matching source IP. =C2=A0 Once the first fragment is allowed, the subsequent fragments are let through.=C2=A0 The source IP i= s checked later in the implementation and thus the hacker gets into the network.=C2=A0 An authentication server servi= ng the router is the last defense against such a hack because a login and password is required.=C2=A0

 Remember that an IPv4 packet with DF=3D0 can be fragmented anywhere in the network and both IPv4 and IPv6 can be fragmented at the source.

IPv4 requires that a 68 byte packet can traverse the net without fragmentation but there are no rules that prohibit smaller packets or fragments. E.g., if you are sending a 100-byte packet and it needs to be fragmented down to 68 bytes, it's entirely valid to make the first fragment as 32 bytes. Anything longer than the IP header ought is defined as valid.

<hs> When I get the time, I will check the Linux code and see if it has anything hard coded for minimum IPv4 packet size.=C2=A0 Thanks for your other repli= es - make total sense.=C2=A0 I am all set.

Best Regards,

Hemant=C2=A0




--94eb2c130572bcb79905467bc613-- From nobody Thu Jan 19 17:01:21 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39ADC129505 for ; Thu, 19 Jan 2017 17:01:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 F25L8vu_3z2Q for ; Thu, 19 Jan 2017 17:01:19 -0800 (PST) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBF37129440 for ; Thu, 19 Jan 2017 17:01:18 -0800 (PST) Received: by mail-ua0-x22a.google.com with SMTP id 35so49986712uak.1 for ; Thu, 19 Jan 2017 17:01:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=k19sfpP30RSonUx8YKhcc18T2sKlCLYowMI4EokfhDM=; b=it09FTmzhSpAf4yuVaQ2fttK9CjC070DO4ms9W2SsI7aWQ8ZEyriLGLSPxDkGiRIQm QR2Bp86+rWKM14f0CXVnXEMZMY9OtPc1l8bXwYkXeaNO50asAjpwZXgbfOd+XYoIjnwq 3OpTvtjAGEYpASpGVL6hDSPKD6dhVoosT1v944Llloina/fR4yDKRS9yFCJWYMmeFDYO JGsJ61i+2xzL7u/jhTpO+15lHzjVadCyf0woiMaftpVt3XaRZFd1sQSn6erTL9wMOapx +1r6cvbgox8O5NGzaRwqpghS8ZuuBP7URjahPQwiK3rCzXayzt7NY7yCdFdxo8a1QLT1 jWYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=k19sfpP30RSonUx8YKhcc18T2sKlCLYowMI4EokfhDM=; b=I11CacFDpdZRm2J4K/qgmAkFaBcetFE4S0W9EHQjddnaP852LCubfPLnDwloHMhs11 DAZWnHPOxfBV6HJp9EXJkrslRM6dyzUsb/D7BTVSMieLeltIqRgS3tNVsk81loeifz8M lqAsagBDhQdnxk0nWKls0sEGVFe8N13l4WwCAsLIKqX9C9i0yMbW1LgKFIjqEsbjP/Em ovKR27d7uCuNwaAYl/+BskL3uR+N1xMzVyOnIo8K3UUiWBLJQpEvzjqXAkII+2ZddtJH a71pEsty04LkY3mbSomT73iZCKMIz6zuCSNxpGF0es798fmrter58pcJFVLzAMq28fMv J09A== X-Gm-Message-State: AIkVDXJHxMX8EnI0WXikZp+fDn5XRL0yxIMm7dNWyBmb+cKf/7CEoUsQc4QAdGxpukQAVPFAB5WT3ifKC4REoZFS X-Received: by 10.176.65.101 with SMTP id j92mr6637279uad.57.1484874077709; Thu, 19 Jan 2017 17:01:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.171.2 with HTTP; Thu, 19 Jan 2017 17:00:56 -0800 (PST) In-Reply-To: <20170119203126.GX2891@angus.ind.wpi.edu> References: <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <20170117.170305.74705723.sthaug@nethelp.no> <20170119132836.GO1862@angus.ind.wpi.edu> <20170119165247.GV2891@angus.ind.wpi.edu> <20170119203126.GX2891@angus.ind.wpi.edu> From: Lorenzo Colitti Date: Fri, 20 Jan 2017 10:00:56 +0900 Message-ID: To: Chuck Anderson Content-Type: multipart/alternative; boundary=94eb2c122f9ef0845205467c2f62 Archived-At: Cc: Fernando Gont , v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 01:01:20 -0000 --94eb2c122f9ef0845205467c2f62 Content-Type: text/plain; charset=UTF-8 On Fri, Jan 20, 2017 at 5:31 AM, Chuck Anderson wrote: > > Meh. draft-bowbakova-rtgwg-enterprise-pa-multihoming-01 is the way to > go. > > Boo. > > "How a host should make good decisions about source address > selection in a multihomed site is not a solved problem. We do not > attempt to solve this problem in this document." > There's no way around that if you want end-to-end without BGP. At the end of the day, a decision needs to be made on what source address to use for a packet. The totality of the options, as I see them, is: 1. You do end-to-end, in which case the host has to choose the right source address. 2. You do NAT and the local network decides the source address for you without telling the host. 3. You do BGP and everyone else on the Internet decides for you. Ultimately we need to move away from transport protocols that are strongly bound to the source IP address. For example, QUIC has no such restriction as it provides a proper layer 4 connection ID. --94eb2c122f9ef0845205467c2f62 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Jan 20, 2017 at 5:31 AM, Chuck Anderson <cra@wpi.edu> wrote:=
= > Meh. draft-bowbakova-rtgwg-enterprise-pa-multihoming-01 is the wa= y to go.

Boo.

=C2=A0 "How a host should make good decisions about source address
=C2=A0 =C2=A0selection in a multihomed site is not a solved problem.=C2=A0 = We do not
=C2=A0 =C2=A0attempt to solve this problem in this document."

There's no way = around that if you want end-to-end without BGP. At the end of the day, a de= cision needs to be made on what source address to use for a packet. The tot= ality of the options, as I see them, is:
  • You do end-to-end, in which case the host has to choose the right sou= rce address.
  • You do NAT and the local network decides the source ad= dress for you without telling the host.
  • You do BGP and everyone els= e on the Internet decides for you.
    • Ultimately we need to move= away from transport protocols that are strongly bound to the source IP add= ress. For example, QUIC has no such restriction as it provides a proper lay= er 4 connection ID.
    --94eb2c122f9ef0845205467c2f62-- From nobody Thu Jan 19 17:24:47 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DDF012946F for ; Thu, 19 Jan 2017 17:24:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 cGYkg0UbS9TR for ; Thu, 19 Jan 2017 17:24:44 -0800 (PST) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7186129410 for ; Thu, 19 Jan 2017 17:24:44 -0800 (PST) Received: by mail-yw0-x22f.google.com with SMTP id l19so60132868ywc.2 for ; Thu, 19 Jan 2017 17:24:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=AjfHK9jGF9Tri5CAP5akYhaezmEWYFYPuO+GyhHv0eI=; b=xMtjjcFbfPWqIyLOXmQ1+UjDKn+9U3apSXuSHWuo8AuVk6tXtmRkcFjBSUwJhECeh2 kdiPehG0kuPXW2/3CVTsIPYAe5RglnR1Si9r3GeiOeWjMIplEsqAvhufLjTYvnPL2oEW 5SxbLGBkeDPCdRjj1gfO9vxz+xab3SCjnEE+lXKK2v2vneW9oUkkTvQFkRZi0QUhzGK3 ZbAISor0PxkE1sdg+IzuQixzhRVbT0hp5dwXe6SdcbHk62nqQhSyvqsdfezgaBQRnOLl 89ke9VENl8bQCSDAiUrHUJXquhxWEBR/bBn1YJxbYdHjUpcbXLuX+z4jQStkXJ6U96MF NPig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=AjfHK9jGF9Tri5CAP5akYhaezmEWYFYPuO+GyhHv0eI=; b=ZKvR0OyflQYmlKVmEuPzSW48ugddtXZ3gmOEzgER1a/Es1xvdFitIbt3BaHHbCGpnV B7pWBoXtIuZJcAOx4AKuDoZsDCBxchumjOooRW7pZyV79XvaecnEItDo7paW+ZoEBkG3 euphQ6CDeC/J5Br5PdGFnyihCL29Xzk4IzK6LBWaxStj6v0Ltq+tGuP7XY8wO3SeymeY nJQqDWUH1353K8cnlbUrz82R8RyQFuRX2DoqLgsmHarETUa6jSAwwTxDspR6fYV+uMsa RMOxw8t0jyNr0JxtmYZVtEVAMlnyb6xg/jngU9+M8cMpUm3weg0wWbKpMkZlXJv7aVWe ymWg== X-Gm-Message-State: AIkVDXJiepejg/jgm4WgX7nyhmbFIVDEgQdk82mt7k4uKRhdq0En1o6uv5jn/yqSFJN01Q== X-Received: by 10.55.76.204 with SMTP id z195mr6180987qka.128.1484875483963; Thu, 19 Jan 2017 17:24:43 -0800 (PST) Received: from [192.168.1.228] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id n18sm4635962qtc.4.2017.01.19.17.24.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Jan 2017 17:24:41 -0800 (PST) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_27D63C87-5847-4ABC-B8E0-6259AF0B3C8F" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Thu, 19 Jan 2017 20:24:40 -0500 In-Reply-To: <142D26B7-D560-46C8-96BD-EE42DBD84183@google.com> To: james woodyatt References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <99204933-5CB6-4E89-BD6A-FD40136DF6F5@steffann.nl> <207A1D5B-4FF6-4E50-B6D0-4EF7DD6AB9A1@google.com> <142D26B7-D560-46C8-96BD-EE42DBD84183@google.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 01:24:46 -0000 --Apple-Mail=_27D63C87-5847-4ABC-B8E0-6259AF0B3C8F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jan 19, 2017, at 7:22 PM, james woodyatt wrote: > I smell a logical circle in there: there hasn=E2=80=99t been a = stronger push to support DHCPv6 Reconfigure in information requests = because the kinds of services that are distributed via Stateless DHCP = are not the sort that have the plumbing available to use it, and there = hasn=E2=80=99t been a stronger push to make more kinds of services = distributed via Stateless DHCP because there isn=E2=80=99t support for = DHCPv6 Reconfigure in information requests. Sure, but I think we both agree that those kinds of services are better = served using DNSSD. The issue is that some small subset of services = are probably better configured via ND or DHCP. E.g., DNS resolver. --Apple-Mail=_27D63C87-5847-4ABC-B8E0-6259AF0B3C8F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Jan 19, 2017, at 7:22 PM, james woodyatt <jhw@google.com> = wrote:
    I smell a logical circle in there: there = hasn=E2=80=99t been a stronger push to support DHCPv6 Reconfigure in = information requests because the kinds of services that are distributed = via Stateless DHCP are not the sort that have the plumbing available to = use it, and there hasn=E2=80=99t been a stronger push to make more kinds = of services distributed via Stateless DHCP because there isn=E2=80=99t = support for DHCPv6 Reconfigure in information = requests.

    Sure, but I think we both agree that those kinds of services = are better served using DNSSD.   The issue is that some small = subset of services are probably better configured via ND or DHCP.   = E.g., DNS resolver.

    = --Apple-Mail=_27D63C87-5847-4ABC-B8E0-6259AF0B3C8F-- From nobody Thu Jan 19 18:35:04 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F3E51296E5 for ; Thu, 19 Jan 2017 18:35:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 hgCgu4VtNGbC for ; Thu, 19 Jan 2017 18:35:01 -0800 (PST) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 396261296DD for ; Thu, 19 Jan 2017 18:35:00 -0800 (PST) Received: by mail-vk0-x22f.google.com with SMTP id t8so43372573vke.3 for ; Thu, 19 Jan 2017 18:35:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8yarauk1UxHt57dUSni4L4TIhDJtRz3vq9Z/yEOIEBI=; b=Die4x1txNQMMlbngyjkL26aw95WLyfIPClEbTVW5ku5rsHsjueudxVDezDjjp6pKlc rrRMCleLKsB40gieV7VcSeGSKsztwIqYbgyKjnNt9oWz+zFkONJ3QOmbH6rR7WkhPhwX cMez+A22FynMt03Nfi78vstZbZNEAc8j0s0Ss4AB5ZKOFsJEGXqmTcHarc1wHoeu52Ap GyvEbxiX2Xnw7VCA/MdjZ6025NOD9WEA/CX1ZkcQv98GgPlKhtAxQa1yQshLaNI/NX7k GI94Pt3wllbKXhKFisMspUI4eRwy2hdujiWM2fcfhnsz5aZgPya5RMF6eBWdGPw0CFrH zdWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8yarauk1UxHt57dUSni4L4TIhDJtRz3vq9Z/yEOIEBI=; b=mDAyQ7hIML/6GuHa3JA1232jdkASOmYXPhZkU0YAZ+t3JL4MgdREMQxPk7iCATHLIi FXfGacGlrOUjj9GxK9m8wDFlBeBeWC1Tvmega9+zgkRlGjkmu3C/xEXVq8YqAlOO2S3z cjwJFNcXYLukCQXPlmmgLNzlBFbCbjkOb1QdfLHqyQTk0wYLFDBV51pdwcLY6wyyArpO du5W0wcLAAScFsgj/8OWYQR51u89luDr98z383nu39I5npnU9pnodw8pXtvStQ28ZrHo RFfNibCHALYEBNBVW1tsRI0Sl1br2bUx/hfc5oJ6xoGKm4Ppuma63DfSSMCG4x9/DUmR M7bw== X-Gm-Message-State: AIkVDXLMRcuxwRz8LcLLwD7kCCwi3d3MfwfDysnEGMefVspJB1SJwB1a9S9AOHZ2D0pn8XekzP+6MdGPryxpRTeT X-Received: by 10.31.88.1 with SMTP id m1mr6291233vkb.83.1484879699987; Thu, 19 Jan 2017 18:34:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.171.2 with HTTP; Thu, 19 Jan 2017 18:34:38 -0800 (PST) In-Reply-To: <5a275aeadcd943e38d443735acb761a4@XCH-ALN-003.cisco.com> References: <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <20170117.170305.74705723.sthaug@nethelp.no> <20170119132836.GO1862@angus.ind.wpi.edu> <20170119165247.GV2891@angus.ind.wpi.edu> <50240d7e06c3427cabaac463a95cdac2@XCH-ALN-003.cisco.com> <5a275aeadcd943e38d443735acb761a4@XCH-ALN-003.cisco.com> From: Lorenzo Colitti Date: Fri, 20 Jan 2017 11:34:38 +0900 Message-ID: To: "Bernie Volz (volz)" Content-Type: multipart/alternative; boundary=001a114e53640d980305467d7f90 Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 02:35:03 -0000 --001a114e53640d980305467d7f90 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Jan 20, 2017 at 6:46 AM, Bernie Volz (volz) wrote: > I do regret not being more active when RFC 7934 was being drafted as I > think there are some things about DHCPv6 that are a bit off. > > > > It is also technically possible for a client > > to request additional addresses using a different DHCP Unique > > Identifier (DUID), though the DHCPv6 specification implies that > > this is not expected behavior ([RFC3315], Section 9 > ). > > > > The way a client can get many addresses is simply to send in multiple > IA_NA (or IA_TA or IA_PD) options with different IAID values. There is no > need to change the DUID. > That's true, but the sentence immediately prior to the one you cite already says that that DHCPv6 can provide multiple addresses: o Using stateful DHCPv6 address assignment [RFC3315]. Most DHCPv6 clients only ask for one non-temporary address, but the protocol allows requesting multiple temporary and even multiple non- temporary addresses, and the server could choose to provide multiple addresses. and the text about changing DUIDs is in addition to that. > The maximum number of IPv6 addresses that can be provided > > in a single DHCPv6 packet, given a typical MTU of 1500 bytes or > > smaller, is approximately 30 > > > > But a client is free to send many separate transactions (multiple > packets). For example, one approach would be to send a new request whenev= er > a new address is needed =E2=80=93 this would be an IA_NA (for non-tempora= ry > address) with a unique IAID. And, that might be much easier when you have > dynamic needs (i.e., device being added over time). > > True, but see below about the impact of this point on the overall recommendation. > Neither of the statements in the RFC is technically wrong (as changing th= e > DUID is certainly one way to accomplish that goal, and the limit for a > single packet is correct). But it just leaves the wrong impression about > DHCPv6. We designed it to allow LOTS of addresses per client and be very > flexible in how those addresses are =E2=80=9Cgrouped=E2=80=9D (i.e., by I= A_* type and IAID). > That's true. However, the most important reason why the document recommends against DHCPv6-only addressing is not related to either of those points, but due to a fundamental property of DHCPv6 IA_NA: the fact that addressing via IA_NA requires explicit requests for address space before addresses can be assigned. This is the applicable text: Due to the drawbacks imposed by requiring explicit requests for address space (see Section 4), it is RECOMMENDED that the network give the host the ability to use new addresses without requiring explicit requests. This can be achieved either by allowing the host to form new addresses autonomously (e.g., via SLAAC) or by providing the host with a dedicated /64 prefix. The prefix MAY be provided using DHCPv6 PD, SLAAC with per-device VLANs, or any other means. Cheers, Lorenzo --001a114e53640d980305467d7f90 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    On F= ri, Jan 20, 2017 at 6:46 AM, Bernie Volz (volz) <volz@cisco.com> wrote:

    I do regret not being more active when RFC 7= 934 was being drafted as I think there are some things about DHCPv6 that ar= e a bit off.

    =C2=A0

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2= =A0=C2=A0It is also technically possible for a client<= /p>

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 to request additi= onal addresses using a different DHCP Unique

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Identifier (DUID)= , though the DHCPv6 specification implies that

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 this is not expec= ted behavior ([RFC3315], Section=C2=A09).

    =C2=A0

    The way a client can get many addresses is s= imply to send in multiple IA_NA (or IA_TA or IA_PD) options with different = IAID values. There is no need to change the DUID.


    That'= s true, but the sentence immediately prior to the one you cite already says= that that DHCPv6 can provide multiple addresses:

    = =C2=A0 =C2=A0o =C2=A0Using stateful DHCPv6 address assignment [RFC3315].=C2= =A0 Most DHCPv6
    =C2=A0 =C2=A0 =C2=A0 clients only ask for one non= -temporary address, but the protocol
    =C2=A0 =C2=A0 =C2=A0 allows = requesting multiple temporary and even multiple non-
    =C2=A0 =C2= =A0 =C2=A0 temporary addresses, and the server could choose to provide
    =C2=A0 =C2=A0 =C2=A0 multiple addresses.=C2=A0=C2=A0

    and the text about changing= DUIDs is in addition to that.
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 =C2=A0The maximum number of IPv6 addresses that can be provide=
d
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 in a single=
 DHCPv6 packet, given a typical MTU of 1500 bytes or

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 smaller, is=
 approximately 30
    

    =C2=A0
    

    But a client is free to send many separate t=
ransactions (multiple packets). For example, one approach would be to send =
a new request whenever a new address is
 needed =E2=80=93 this would be an IA_NA (for non-temporary address) with a=
 unique IAID. And, that might be much easier when you have dynamic needs (i=
.e., device being added over time).
    <= div>
    True, but see below about the impact of this point on th= e overall recommendation.
    =C2=A0

    Neither of the statements in the RFC is technically wrong = (as changing the DUID is certainly one way to accomplish that goal, and the= limit for a single packet is correct). But it just leaves the wrong impression about DHCPv6. We desi= gned it to allow LOTS of addresses per client and be very flexible in how t= hose addresses are =E2=80=9Cgrouped=E2=80=9D (i.e., by IA_* type and IAID).=


    That's true. Ho= wever, the most important reason why the document recommends against DHCPv6= -only addressing is not related to either of those points, but due to a fun= damental property of DHCPv6 IA_NA: the fact that addressing via IA_NA requi= res explicit requests for address space before addresses can be assigned. T= his is the applicable text:

    =C2=A0 =C2=A0Due to th= e drawbacks imposed by requiring explicit requests for
    =C2=A0 =C2= =A0address space (see Section 4), it is RECOMMENDED that the network
    <= div>=C2=A0 =C2=A0give the host the ability to use new addresses without req= uiring
    =C2=A0 =C2=A0explicit requests.=C2=A0 This can be achieved= either by allowing the host
    =C2=A0 =C2=A0to form new addresses a= utonomously (e.g., via SLAAC) or by providing
    =C2=A0 =C2=A0the ho= st with a dedicated /64 prefix. The prefix MAY be provided
    =C2=A0= =C2=A0using DHCPv6 PD, SLAAC with per-device VLANs, or any other means.

    Cheers,
    Lorenzo=C2=A0
    --001a114e53640d980305467d7f90-- From nobody Thu Jan 19 18:47:27 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FC851296FF for ; Thu, 19 Jan 2017 18:47:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 v2fn5Ae5AWdE for ; Thu, 19 Jan 2017 18:47:24 -0800 (PST) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7EC31296DD for ; Thu, 19 Jan 2017 18:47:24 -0800 (PST) Received: by mail-pg0-x22b.google.com with SMTP id 194so19243569pgd.2 for ; Thu, 19 Jan 2017 18:47:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=u3vl2jtpUc51SKNiHSB0GXyR94/j+CQ+GsGa0c04Qks=; b=A1qQuqJf/L56uG4Kcwg5unPNKpxMd7nuKaC+n+JujRY3ozhknz4gHBnmk8YHkSbWdt WljFcNuQBy6UMIxJ6tQzmOhmi+KeRE7Y1nUzTkn1mHJe5Mq4wesjhg8bjOuqJLiGOBY9 Vy6+4nEwK0yMM4dV/7G8YNY8M+3bib+IZsla31nkrotdXweKPeyF57s1LkHgm5bjknJ6 BVBz7bN6sASoRj5HP7TR7b1qXgAk84Lky+TQ4Y+P0ZuFssH0FjzualUTbBFuXyfKPn7i in2jMWZJYzC+bWszZLZkKebLMdwkSayUyZtAywQ5JiCgs2NhWpY/ssInB/B7W+ocWH3b HaqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=u3vl2jtpUc51SKNiHSB0GXyR94/j+CQ+GsGa0c04Qks=; b=DGkEHgbVHjEAGQtRDMWfQfVif1Vaj/6bT1oZgtqgHIa8s5K1G5n8YGIDDFe9nvIap9 edBNR4TlD8gMIH7yAyxRhdD2D29ZquNfP8ZRJzufbojJINMl50LizgMGtqSdCGO89JT7 Mbef+uSixj44ymwKMkywZMBrar25plpI27ldRdQQDLBYg4p7WoRc9Z+BAH7/69p/v4S4 VdVQOaaSajSjwlafPQOaeCjbcWU5Y/hkRMo5HctfDhAXB4/IAidPOVUc8yCKVheJ1ugb jsqbsPjmQZHnqUJ7p75fXtPTMpP+LzZyxoMzxO3NOyc7FhiHo6A8T1MYtaCFaezjIcXR g2yQ== X-Gm-Message-State: AIkVDXIA/DG3+TL9xujYxiQ+2h8N/k4WKLsfg0hSPZxZn4mYv2fU80BDLoyXuIg195oMKA== X-Received: by 10.84.218.71 with SMTP id f7mr17872880plm.59.1484880444233; Thu, 19 Jan 2017 18:47:24 -0800 (PST) Received: from ?IPv6:2406:e007:44fc:1:28cc:dc4c:9703:6781? ([2406:e007:44fc:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id r1sm11820698pgn.48.2017.01.19.18.47.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Jan 2017 18:47:23 -0800 (PST) To: Mark Smith , james woodyatt References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <99204933-5CB6-4E89-BD6A-FD40136DF6F5@steffann.nl> From: Brian E Carpenter Organization: University of Auckland Message-ID: <3ebea184-926c-8c2a-bf8c-cf6514874821@gmail.com> Date: Fri, 20 Jan 2017 15:47:24 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 02:47:26 -0000 On 20/01/2017 08:43, Mark Smith wrote: ... > Brian has said RDNSS was aimed less resource constrained environments > such as cafes, homes etc. Unfortunately that doesn't seem to be that > clear, as much larger organisations are seeming to see it as the > general purpose way of deploying DNS parameters... Could that possibly be because DHCPv6 doesn't support next-hop router advertisements, and they know that all hosts need both a DNS server and a next-hop router? And for most hosts, that's *all* they need once they have an address. It isn't the first time in IETF history that a protocol feature has been used for unexpected purposes. Brian From nobody Thu Jan 19 18:52:40 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE8A129717 for ; Thu, 19 Jan 2017 18:52:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Bl9V5XJ24YnQ for ; Thu, 19 Jan 2017 18:52:37 -0800 (PST) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C0AF129712 for ; Thu, 19 Jan 2017 18:52:37 -0800 (PST) Received: by mail-pf0-x229.google.com with SMTP id y143so18414530pfb.0 for ; Thu, 19 Jan 2017 18:52:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=zpkFReEGsXO0tw17eCkFYTyewc3GzwOjsbNr/nJ31NA=; b=Zp//1YXnpZ4SVgHsvhtTsVDgMA0PHTpHozn8hoGydAoUAWkBge1MPDJeYYt1kR2NHf ZTPUvqyQb54WwJ2yvIP7xoK8RMgr/QGHCnJVaAidUlS+Va5Bvu6yoNV081NGYMmcRU4L jkHySAcWky11N2sIdIPFyuJiPjFfy5hu8nMw16ysjcONl1FOkBBaJKBFyYxRxNCkVwh5 Hv/SCTJIathByLPpVYyJ3pl9VSfitSnbIqR7V/He0j89wLfdFxxAmbhyJk3GQOY5lKVD s8tb54r0/rMg9SYv9krZcgS34lbYQ46Yw0g2NlTfonx0BpL4CRZrFGcagtSiVJBmS6um GhHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=zpkFReEGsXO0tw17eCkFYTyewc3GzwOjsbNr/nJ31NA=; b=q3xMKehB8cqJ32sfVqzAlvb6Es8fbOhkGjaI9RPa++ND5Zpbp1TRwLmtuXR4WpwBwh mxDZTcDnGIow7mHWikjWewYbebaZ9xXz4Ixmn1tWlE5Hj1na+YnYfUihcfCYKBmXM61D 2zLjMaHAmmew777YQof66BRtZP5v1LrCs4oOTyhKtTryilxpHoOMMJ6rM6GnzB+/DqaR AZL0H2EStTNrWvBhConp+mjkSRr9JO3oeNlP+BpW35uAfON0SnfscIKk7ah0Xny5pGSu jSe44krm+rbp5yyePlCHEEOxj1uVmjgXTS8mMf9WPF6sbDZif+38jMU2Hcucr5rnfbc6 +NCw== X-Gm-Message-State: AIkVDXLJWTrUkiFQcR2diRsoPbQOa2ZdmzJ+i08zRHt/f4n+THJtoA/CNHHbZjUiZEMDMA== X-Received: by 10.99.184.18 with SMTP id p18mr14314822pge.33.1484880756569; Thu, 19 Jan 2017 18:52:36 -0800 (PST) Received: from ?IPv6:2406:e007:4482:1:28cc:dc4c:9703:6781? ([2406:e007:4482:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id s17sm11920058pgo.27.2017.01.19.18.52.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Jan 2017 18:52:35 -0800 (PST) To: Lorenzo Colitti , Chuck Anderson References: <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <20170117.170305.74705723.sthaug@nethelp.no> <20170119132836.GO1862@angus.ind.wpi.edu> <20170119165247.GV2891@angus.ind.wpi.edu> <20170119203126.GX2891@angus.ind.wpi.edu> From: Brian E Carpenter Organization: University of Auckland Message-ID: <78fd38c6-b5bd-fdc2-7f62-701139e0c08e@gmail.com> Date: Fri, 20 Jan 2017 15:52:38 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Fernando Gont , v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 02:52:38 -0000 On 20/01/2017 14:00, Lorenzo Colitti wrote: > On Fri, Jan 20, 2017 at 5:31 AM, Chuck Anderson wrote: > >>> Meh. draft-bowbakova-rtgwg-enterprise-pa-multihoming-01 is the way to >> go. >> >> Boo. >> >> "How a host should make good decisions about source address >> selection in a multihomed site is not a solved problem. We do not >> attempt to solve this problem in this document." >> > > There's no way around that if you want end-to-end without BGP. At the end > of the day, a decision needs to be made on what source address to use for a > packet. The totality of the options, as I see them, is: > > 1. You do end-to-end, in which case the host has to choose the right > source address. Actually the real point is to choose the right couplet {source_address, next_hop}. Once again, that's why we did RFC 8028, which includes recommending Rule 5.5 of RFC6724. It's not a panacea, and we still need RTGWG to do something, but we are moving along the right path, I think. Brian > 2. You do NAT and the local network decides the source address for you > without telling the host. > 3. You do BGP and everyone else on the Internet decides for you. > > Ultimately we need to move away from transport protocols that are strongly > bound to the source IP address. For example, QUIC has no such restriction > as it provides a proper layer 4 connection ID. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Thu Jan 19 20:11:47 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25823126BF7 for ; Thu, 19 Jan 2017 20:11:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 eOQtHeKlTRhF for ; Thu, 19 Jan 2017 20:11:43 -0800 (PST) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFD0B126579 for ; Thu, 19 Jan 2017 20:11:43 -0800 (PST) Received: by mail-ua0-x231.google.com with SMTP id 96so52127789uaq.3 for ; Thu, 19 Jan 2017 20:11:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Oa25QgXwpKleZUs/RvwdAiSGrra+Tw9HlJtp/IxkXCQ=; b=EB4YH5087D5ev/8vQ5Q4USNuR4erTHFcmfijWtVwoGkL/8jyWc/5SFc5VJibu5q9r7 nUPGGz6gv+pjCfn+Wa29DIUqWaP87TvOtEWqZdZj224WJNGtDQmhxevlXPPYesiP9IMg MEiNqIEOa7EhRXXdMdN4wdgxGn6Vks+IK3d5urgIPTFdHp7/rEMR++dCpxLXA5f+VaPn IfxI5+lNAEKubXyLtFA5EI0993Zzb7IQ1u7LR3+Mp6GMi4Al/ACuiyP3BGTzSYVzC83x hVRJko8Uqimhi8JjLm7VDfydfL2UJMjvNq8jnnYGD6atTabbsR4m5FoUTtnRqQ8hQ0sz 9pTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Oa25QgXwpKleZUs/RvwdAiSGrra+Tw9HlJtp/IxkXCQ=; b=WXHDfgZvO+FzE6WraAqJaBos3k9AzN20nwjBlvCdWdwfdYs7LOtxqvh8/3/ygxzYn8 GxUqf0OQUu/S8wt+ALjZV+8zdqbY2fFWa8K39IxLt3B4LolmDg2YyOrIn32ZPEQ0YgPw pzdOv10xy/gIh2dvwIyZ41BITzUSHHTJqGfs25ZwllyTHkV/TBeB7SsBuH46XXIGDToG LcNKMoQC18v+FaBlS4CtfZLKy2Uy8uZd/kXfSJxRWKv6CzN5IHjDsTzq2hy9Oxi0r0Lk vuvRgBz6+iCAa6Z3HRoHlGgrCQM4ITIrUTVKSStcmtn0+pmi8fHH5HZmk3VxHSCpZXMm wX0Q== X-Gm-Message-State: AIkVDXIjo3BBwsPKRApsYgvg42A7C8WfxjZtzznpPmdPjH7NcYqBP1+Qiq0HQATocTsBob/NeNaiLsHn456f1VQx X-Received: by 10.159.38.73 with SMTP id 67mr5715436uag.155.1484885502743; Thu, 19 Jan 2017 20:11:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.171.2 with HTTP; Thu, 19 Jan 2017 20:11:21 -0800 (PST) In-Reply-To: <207A1D5B-4FF6-4E50-B6D0-4EF7DD6AB9A1@google.com> References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <99204933-5CB6-4E89-BD6A-FD40136DF6F5@steffann.nl> <207A1D5B-4FF6-4E50-B6D0-4EF7DD6AB9A1@google.com> From: Lorenzo Colitti Date: Fri, 20 Jan 2017 13:11:21 +0900 Message-ID: To: james woodyatt Content-Type: multipart/alternative; boundary=001a114950dceca8e705467ed8fc Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 04:11:45 -0000 --001a114950dceca8e705467ed8fc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Jan 20, 2017 at 8:50 AM, james woodyatt wrote: > > I would argue that's because Stateless DHCPv6 is not a very good idea. I > believe its sunset should have begun years ago when DNS-SD was standardiz= ed. > > Why am I not a fan of Stateless DHCPv6? Because there isn=E2=80=99t a way= for the > service advertiser to update or delete a service location previously > provided to hosts except to let its timer expire. For that, you need to u= se > DNS-SD. > What James said. Personally I think the biggest issue with DHCP is the that the D in its name is a lie. :-) DHCP is not really dynamic - it's a timer-based protocol that relies on client refresh to change anything. For a long time stateless DHCP didn't have any refresh timer at all. Even now, the minimum refresh time for stateless DHCPv6 is a (laughably long) 600 seconds, which means that if you want to change something you need to wait an average of 5 minutes. --001a114950dceca8e705467ed8fc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    On F= ri, Jan 20, 2017 at 8:50 AM, james woodyatt <jhw@google.com> = wrote:
    I would argue that's because Stateless DHCPv6 is = not a very good idea. I believe its sunset should have begun years ago when= DNS-SD was standardized.

    Why am I not a fan of St= ateless DHCPv6? Because there isn=E2=80=99t a way for the service advertise= r to update or delete a service location previously provided to hosts excep= t to let its timer expire. For that, you need to use DNS-SD.

    What James said. Personally I think the bigge= st issue with DHCP is the that the D in its name is a lie. :-)
    DHCP is not really dynamic - it's a timer-based protocol t= hat relies on client refresh to change anything. For a long time stateless = DHCP didn't have any refresh timer at all. Even now, the minimum refres= h time for stateless DHCPv6 is a (laughably long) 600 seconds, which means = that if you want to change something you need to wait an average of 5 minut= es.
    --001a114950dceca8e705467ed8fc-- From nobody Thu Jan 19 20:47:00 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28F4712950D for ; Thu, 19 Jan 2017 20:46:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.2 X-Spam-Level: X-Spam-Status: No, score=-5.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se 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 TqBrGSDW3zKO for ; Thu, 19 Jan 2017 20:46:56 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 396431297E1 for ; Thu, 19 Jan 2017 20:46:56 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id BBAA9A3; Fri, 20 Jan 2017 05:46:53 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1484887613; bh=Rs3Hp54yq8CZJSlgO3qffui3u6QLm4nKx4P9gjhzoNQ=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=sto+MSgoUs74eioMuF0T+yJvTwKqV1TFf3QrvRFEnDdxEUOawz1pekT8UeiPARUzz XVGpXSd95cZ1KRrnGdBZXX+GimsXLgb4wVzuG0PCYTd2p5hV7lAfZ2Z/SeyK3PqNCx lQ0oIIgfjTxMcPn4J86mVS9aKMiqm0iyHAsnUJr0= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id B6067A2; Fri, 20 Jan 2017 05:46:53 +0100 (CET) Date: Fri, 20 Jan 2017 05:46:53 +0100 (CET) From: Mikael Abrahamsson To: james woodyatt In-Reply-To: Message-ID: References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <99204933-5CB6-4E89-BD6A-FD40136DF6F5@steffann.nl> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 04:46:58 -0000 On Thu, 19 Jan 2017, james woodyatt wrote: > If there is a movement to load more options into RA Messages than those > necessary for providing hosts with DNS configuration even when they In order to make DNSSEC validation work, there might be a need to put NTP server in RA as well. There are other options that have gone into RA lately, that probably hasn't been widely noticed. For instance there is a captive portal option for RA. > leaders. There is no reasonable need for additional service location > information pushed in RA Messages beyond the DNS servers and name search > parameters because we have DNS-SD for providing network parameters to Errr, DNS-SD? What kind of network parameters are you talking about? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Jan 19 21:00:26 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69A6F12985C for ; Thu, 19 Jan 2017 21:00:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 eWmtv3JT-ieN for ; Thu, 19 Jan 2017 21:00:24 -0800 (PST) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFCF3129858 for ; Thu, 19 Jan 2017 21:00:23 -0800 (PST) Received: by mail-yw0-x22b.google.com with SMTP id w75so68621571ywg.1 for ; Thu, 19 Jan 2017 21:00:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=iY0tNnabORjWcVyCuKUZXIU80UHDgSFxjTbQc6xTz+E=; b=TjVVKM9uJkHOpgCGmj3xDZacEWMQ2QSTXXSqUuFaKy0TCkqYlIJnkBYM10mCdQ45+Y w2bw7Hs0pTT3UL2AfJ2hIfUW93yhDsoXbL4njjTDQ3FphdcqFYU/9VAysVZ+ehRGXKx6 BdL9rRnA/dPjE8hRfoVSuBgs3Ua6z1vo3mXsY8MTQpXRE22iF9mmvrV3ySu3rlFMvG+I y7gYp/zUIpioIPwgV/Li99AWjcdc5FT/n9aWZ8ad60TuNvKxQ4VU7aeJWIKbp2Zo8QNC npN6qe2LY6yM8rHGl0LJlRq2lzuXhZiir1w+rOJHeq8rKm9573bneW/3+agb7KM447lQ xj5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=iY0tNnabORjWcVyCuKUZXIU80UHDgSFxjTbQc6xTz+E=; b=XV11JmujArMMDYAfZPLzSAwZH0sW4NozSEo6J2F7PsNbuANaZKIGEa/w+ReSg8oxgM 3UNvb+6sI453VJieHz5gPaw+sh5Z9tn0LbyI7D+LejlST//kDszovpG++iWUW47vPE71 MWSnpsl28vPO4xW4v53KEk95nH5eY4Yn7RNE0fS4YtP38uZ67hIBTeQSzUnSweTQBR9s p8DwY0AlQF1GL9+OwVTlPR/5M4lA/8H+q7zQMmlWeZkyMvQLBqCDo5lutRxtT2GfaH8v 1pxREqE5eIpwWhdM67DytRF/pAsh8pNHra0cOVRbP89YkqHWz2T/RpY8HidE0Vc8HYbj euBA== X-Gm-Message-State: AIkVDXJoxHEr8WWRV08HEfgEbQScCma8QyhENkr2/FgQTgAdwOpgJCVIeVXAgdUpUjUhOQ== X-Received: by 10.200.42.227 with SMTP id c32mr10547535qta.70.1484888423123; Thu, 19 Jan 2017 21:00:23 -0800 (PST) Received: from [192.168.1.228] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id h40sm5038543qtb.6.2017.01.19.21.00.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Jan 2017 21:00:21 -0800 (PST) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_923CB43F-D71D-4923-B27D-C0D412496CA8" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Fri, 20 Jan 2017 00:00:20 -0500 In-Reply-To: To: Mikael Abrahamsson References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <99204933-5CB6-4E89-BD6A-FD40136DF6F5@steffann.nl> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: james woodyatt , IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 05:00:25 -0000 --Apple-Mail=_923CB43F-D71D-4923-B27D-C0D412496CA8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jan 19, 2017, at 11:46 PM, Mikael Abrahamsson = wrote: > In order to make DNSSEC validation work, there might be a need to put = NTP server in RA as well. You must have missed the discussion we had on this very topic earlier = today. This is a problem nobody is trying to solve, because it's = already solved a different way. --Apple-Mail=_923CB43F-D71D-4923-B27D-C0D412496CA8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Jan 19, 2017, at 11:46 PM, Mikael Abrahamsson <swmike@swm.pp.se> = wrote:
    In order to make DNSSEC validation work, there = might be a need to put NTP server in RA as well.

    You = must have missed the discussion we had on this very topic earlier today. =   This is a problem nobody is trying to solve, because it's already = solved a different way.

    = --Apple-Mail=_923CB43F-D71D-4923-B27D-C0D412496CA8-- From nobody Thu Jan 19 21:03:14 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54E2F1295EA for ; Thu, 19 Jan 2017 21:03:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.1 X-Spam-Level: X-Spam-Status: No, score=-10.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 dqsVS5VRlUMq for ; Thu, 19 Jan 2017 21:03:11 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE04D1295E0 for ; Thu, 19 Jan 2017 21:03:11 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 35244349608; Fri, 20 Jan 2017 05:03:09 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 0D3DB16003E; Fri, 20 Jan 2017 05:03:09 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id EB2EE160069; Fri, 20 Jan 2017 05:03:08 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ycj3XM8mHVCd; Fri, 20 Jan 2017 05:03:08 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 6C2A416003E; Fri, 20 Jan 2017 05:03:08 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id B71F25FFB331; Fri, 20 Jan 2017 16:03:04 +1100 (EST) To: Mikael Abrahamsson From: Mark Andrews References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <99204933-5CB6-4E89-BD6A-FD40136DF6F5@steffann.nl> In-reply-to: Your message of "Fri, 20 Jan 2017 05:46:53 +0100." Date: Fri, 20 Jan 2017 16:03:04 +1100 Message-Id: <20170120050304.B71F25FFB331@rock.dv.isc.org> Archived-At: Cc: james woodyatt , IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 05:03:13 -0000 In message , Mikael Abrahamsson writes: > On Thu, 19 Jan 2017, james woodyatt wrote: > > > If there is a movement to load more options into RA Messages than those > > necessary for providing hosts with DNS configuration even when they > > In order to make DNSSEC validation work, there might be a need to put NTP > server in RA as well. DNSSEC really only needs the clock to be set to roughly the correct time. +/- 30 minutes should be fine. The default setting of the signing tools all set the signing time into the past. Clock skew exists and if you don't allow for it you will be putting out answers that don't validate. BIND back dates the signing timestamp by a hour. You are taking a leap of faith if you just trust a unknown time source to set your clock. > There are other options that have gone into RA lately, that probably > hasn't been widely noticed. For instance there is a captive portal option > for RA. > > > leaders. There is no reasonable need for additional service location > > information pushed in RA Messages beyond the DNS servers and name search > > parameters because we have DNS-SD for providing network parameters to > > Errr, DNS-SD? What kind of network parameters are you talking about? > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Jan 19 21:15:10 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 444AA12987A for ; Thu, 19 Jan 2017 21:15:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.5 X-Spam-Level: X-Spam-Status: No, score=-7.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se 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 D4ahYk-EshBl for ; Thu, 19 Jan 2017 21:15:07 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAF67129879 for ; Thu, 19 Jan 2017 21:15:07 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 75E48A3; Fri, 20 Jan 2017 06:15:05 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1484889305; bh=FM9h2AzDaQ4KxmlGvJvuNXCGqiewdYs9UZ6Pb3MUdlE=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=p01pqIqUy5HDVp5+viDo4u059UmOLY6jq3VJbzUxK/5bpq+jFRif5ksTsRaBvJWFW F9+4PhPn54kDQMQ7VCnVa7D7BlmpMG8zRAqfeUAkoCi2NFMuxZmNpBS4E3EYYmqw0u V0nVNJjqbm5B8na+FamoznIcEnpIY5glk7jYvPjw= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 712B3A2; Fri, 20 Jan 2017 06:15:05 +0100 (CET) Date: Fri, 20 Jan 2017 06:15:05 +0100 (CET) From: Mikael Abrahamsson To: Mark Andrews In-Reply-To: <20170120050304.B71F25FFB331@rock.dv.isc.org> Message-ID: References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <99204933-5CB6-4E89-BD6A-FD40136DF6F5@steffann.nl> <20170120050304.B71F25FFB331@rock.dv.isc.org> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: james woodyatt , IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 05:15:09 -0000 On Fri, 20 Jan 2017, Mark Andrews wrote: > You are taking a leap of faith if you just trust a unknown time source > to set your clock. Considering the discussion I started in DNSOP 1-2 months back, it seems there is no solution to this problem. So everybody just throws up hands in air and gives up. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Jan 19 21:16:30 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D07B0129891 for ; Thu, 19 Jan 2017 21:16:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.2 X-Spam-Level: X-Spam-Status: No, score=-5.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se 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 kAiWwIohe6pe for ; Thu, 19 Jan 2017 21:16:27 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0580129880 for ; Thu, 19 Jan 2017 21:16:27 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 2201CA3; Fri, 20 Jan 2017 06:16:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1484889386; bh=sCHRWVsQJP9QocyQdtSN8wEow4gq6orzm5dGaY6WzC0=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=3elfG4Y0F0FmOKRMDYQA8j/DA7YQLHDwV1ezk1XKh2XprG3XoGjUlhBVJc8LvJfke jRDp//H6kKFXWFbKu40ONwZikP+eCEfzN1b30pUU+n7n6tlB8elEBx2tqRrU50tqib FMgGawAPyVQoGhGBIGaRBAMz24W1T+4wKR9/Nako= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 1E9A3A2; Fri, 20 Jan 2017 06:16:26 +0100 (CET) Date: Fri, 20 Jan 2017 06:16:26 +0100 (CET) From: Mikael Abrahamsson To: Ted Lemon In-Reply-To: Message-ID: References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <99204933-5CB6-4E89-BD6A-FD40136DF6F5@steffann.nl> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: james woodyatt , IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 05:16:29 -0000 On Fri, 20 Jan 2017, Ted Lemon wrote: > You must have missed the discussion we had on this very topic earlier > today. This is a problem nobody is trying to solve, because it's > already solved a different way. >From what I can see it's not solved at all. What solution is it you're thinking of? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Jan 19 21:17:34 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBF8C12988A for ; Thu, 19 Jan 2017 21:17:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 sDh-CoOWNVhD for ; Thu, 19 Jan 2017 21:17:31 -0800 (PST) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 767E412987C for ; Thu, 19 Jan 2017 21:17:31 -0800 (PST) Received: by mail-yw0-x22e.google.com with SMTP id l19so69338734ywc.2 for ; Thu, 19 Jan 2017 21:17:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=33VfbWh6RF207WeXvI0Pijct3vXYifGiIX/dPO18nVs=; b=FiiMHje5qLlPhVRXPwPDRxIlGN0ByinDz6mpEEJxDAZnKHMUbCN3wn/MrTEt97o2TZ ykUV43E0LK7aoWaUA8curDAjpf9ButKFugKaq+Td+jkoxwhoIC0UuhizAfalNSsFWnlQ xm+ES16j/H3dvxEBnvHdWbd6bhBnJwITvVwwsLVtXsV2P1F5pSAS3PZuZvDMuqXDFmFX JH5fJG+RsKfD8+ifCqr/WnSwhhnJ5TU0XINtQjce+kIkJtFIx1WdT+35PYbjwv0Xt3+P dgh93cbsymNz6S8HzaCHzBTGg1EnfI8bdxboFbxwzoOEPRNzZWvma5pHMUoOV+UgF322 H4Gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=33VfbWh6RF207WeXvI0Pijct3vXYifGiIX/dPO18nVs=; b=KlfElF9SFa1YmlpFZO6Ha/SXzQ0KlyMNoYZ8VFIwtRpg2gSxOLWfivP7IujfgufOWE mAenAP5dkJjglcG1TpaKk7plJ/j9OYZHXO+QzFBmI5/Orz1+FAzf/XUIy82ymwWR5WSj BwYbxViG7Terh0DizzjXwr9/WB1zk4ska+xuwYSj9eVQUFZZUpQ0Vsmw9Z0RuxgQoHBn 8AMIPlEy81rPHGbs4FzaJWwP8bSqpdqHYTbtH94u9dQnOPpFQX+H3S9eGM+YFtS1+stL SFZgU3e1t0+Ad1gKhGBRmr6nYadCyxcD0cYIvdaPCQLVy7Tw40f7mnRTSlJwgHWoTZui 0YBg== X-Gm-Message-State: AIkVDXISwcMlElrapjYpRSgQPZw7B05k1fv3bahM4/BQYNOJkHeE61VzqIfn3NZrjwvrUQ== X-Received: by 10.237.35.130 with SMTP id j2mr11409374qtc.45.1484889450846; Thu, 19 Jan 2017 21:17:30 -0800 (PST) Received: from [192.168.1.228] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id i5sm5012962qtb.9.2017.01.19.21.17.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Jan 2017 21:17:29 -0800 (PST) From: Ted Lemon Message-Id: <16E38863-B126-42FE-98CD-A4A6B859241C@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_65039015-9C41-40B6-875F-EF765AA22B4D" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Fri, 20 Jan 2017 00:17:28 -0500 In-Reply-To: To: Mikael Abrahamsson References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <99204933-5CB6-4E89-BD6A-FD40136DF6F5@steffann.nl> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: james woodyatt , IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 05:17:33 -0000 --Apple-Mail=_65039015-9C41-40B6-875F-EF765AA22B4D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jan 20, 2017, at 12:16 AM, Mikael Abrahamsson = wrote: > =46rom what I can see it's not solved at all. What solution is it = you're thinking of? No, it's not solved, but adding an NTP option to ND makes it _harder_ to = solve, not _easier_. --Apple-Mail=_65039015-9C41-40B6-875F-EF765AA22B4D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Jan 20, 2017, at 12:16 AM, Mikael Abrahamsson <swmike@swm.pp.se> = wrote:
    =46rom what I can see it's not solved at all. = What solution is it you're thinking of?

    No, it's not solved, but adding an NTP option to ND makes it = _harder_ to solve, not _easier_.

    = --Apple-Mail=_65039015-9C41-40B6-875F-EF765AA22B4D-- From nobody Thu Jan 19 23:22:21 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5A7D129A26 for ; Thu, 19 Jan 2017 23:22:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.4 X-Spam-Level: X-Spam-Status: No, score=-7.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 8FLklGukd6OZ for ; Thu, 19 Jan 2017 23:22:17 -0800 (PST) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with ESMTP id 9B468129A3C for ; Thu, 19 Jan 2017 23:22:17 -0800 (PST) Received: from localhost (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by bizet.nethelp.no (Postfix) with ESMTP id C900BE6065; Fri, 20 Jan 2017 08:22:15 +0100 (CET) Date: Fri, 20 Jan 2017 08:22:15 +0100 (CET) Message-Id: <20170120.082215.74685531.sthaug@nethelp.no> To: mellon@fugue.com From: sthaug@nethelp.no In-Reply-To: References: X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 07:22:19 -0000 > > Hosts have trusted the networks they attach to for more than being > > given an address to since at least BOOTP. Trusting the network being > > attached to for service parameters seems to be a fundamental and many > > decade old assumption, and is the common practice for IPv4 on public > > less trusted networks. > > I don't know of any non-infrastructure devices that use the DHCP-provided NTP server. I performed a small experiment on our residential customers based on this. Many of these customers are on DSL using bridge based modems (so for these customers we see the MAC address of their equipment on our BRAS). I set up a new NTP server (IP never used for NTP before), and changed one of the NTP server addresses we hand out through DHCP to this new address. Within a few minutes, I started seeing NTP traffic from the DHCP clients. Checking the OUI of the MAC addresses I see a mix - both typical "home router" vendors (e.g. Belkin), and also typical host vendors (e.g. HP). Thus my conclusion is that there are certainly *some* hosts picking up NTP servers from DHCP. I couldn't really say anything about how *many* without further analysis. Steinar Haug, AS2116 From nobody Fri Jan 20 02:42:01 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4C6129AFE for ; Fri, 20 Jan 2017 02:41:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=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 SiuRn9f_mEOD for ; Fri, 20 Jan 2017 02:41:52 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 6FA79129AF8 for ; Fri, 20 Jan 2017 02:41:51 -0800 (PST) Received: from stereo.hq.phicoh.net ([::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #127) id m1cUWdh-0000FvC; Fri, 20 Jan 2017 11:41:49 +0100 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bF054DD66@u-1.phicoh.com References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <99204933-5CB6-4E89-BD6A-FD40136DF6F5@steffann.nl> <3503B63B-DF22-4C54-9548-DDB44A638C22@fugue.com> In-reply-to: Your message of "Thu, 19 Jan 2017 19:00:08 -0500 ." <3503B63B-DF22-4C54-9548-DDB44A638C22@fugue.com> Date: Fri, 20 Jan 2017 11:41:48 +0100 Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 10:41:59 -0000 > Perhaps so, but how does your device know to differentiate > between this case and other cases? For 802.1X you need to pin the certificate. So you can just as well add a flag 'this network is trusted' > Also, if it is your personal device that you have brought in to > work, do you necessarily want to accept everything that your > work DHCP server tells your device? That's not a technical problem. I have root on my devices. So I can override network settings as I see fit. There may be devices where the user doesn't have that option. There is not much we can decide about that here. > BTW, I was kidding about DNSSEC. Right now you don't get any > validation, because nothing you're using is signed. I don't know which 'you' you are referring to. I use SSHFP all day. That works perfectly fine, because it is my servers, my DNS, my patched version of ssh. In addition I use the DNSSEC/TLSA Validator plug-in from cz.nic. Funny thing is, their own website https://www.dnssec-validator.cz/ fails to validate that the moment. > And you > should be using ntp with some kind of signing, even if it's > shared private key. Apple doesn't appear to do that, which I > guess isn't shocking (that's my test caseI don't know what other > software is doing). I'm not aware of any secure ntp use at scale. As far as I know ntp security is hugely problematic. If you have any pointers to large scale use of secure ntp I'd like to know. > the fact that this isn't being properly > secured is not a reason to do something dumb security-wise at > the lower layer. Hopefully at some point this problem will be > fixed, and we shouldn't make fixing it harder. Obviously, we first need to figure out how to fix ntp before we can decide on how to distribute the parameters. > That's the deal with DNSSEC as welleven though it isn't broadly > deployed _now_, it will be when it starts to become obvious that > it should be. But the signing infrastructure for DNSSEC allows > for the DNS distributed caching system to work and be secured, > whereas existing NTP authentication does not, and it's unlikely > that that will change. So distributing DNS resolver info with > ND and DHCP doesn't create an additional security exposure; > distributing NTP does. For a security point of view, I don't see a big difference between a starbucks DHCP telling my device to use ntp.starbucks.com and using pool.ntp.org. Both are equally insecure. In a practical sense, using pool is proably better than using whatever was hacked together in a cheap router. From nobody Fri Jan 20 06:42:16 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B6191294D5 for ; Fri, 20 Jan 2017 06:42:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 TR1mDC_1iHTR for ; Fri, 20 Jan 2017 06:42:14 -0800 (PST) Received: from mail-yb0-x229.google.com (mail-yb0-x229.google.com [IPv6:2607:f8b0:4002:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 881F2129404 for ; Fri, 20 Jan 2017 06:42:14 -0800 (PST) Received: by mail-yb0-x229.google.com with SMTP id j82so56366728ybg.1 for ; Fri, 20 Jan 2017 06:42:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=4ucyhqIdlPkmm1GLXkue1DXOIm83PMie+5RUllYQ/dI=; b=1FnIQ8peu3d2nGFpxk8wOhBYypylt3hTZ4+/SrNwH+yd6IzSguDemUU5LquZqg6IzR cuGBC5awC2zx98FW65hVGThwXgcRoQRKe4HRTG9mLcfszfOpSGGUMYJ0hCG/Cj6FTSJP FmwsbhggsuAKcss3tXMOGPZeSZyP5GJTKXHHPcEQzErIO9UlEPb1PlSSL1Uydtgdiab1 4kKlvlSk/efutlqAj/7b+cLPzSEWqekxQioO3duF8uLkN09hjxo4NjAe+CeJ8BEDmnkx lpWU5mmcqSdt/Yt32Mb/LDa+YjAvttCnGCsKhf21sCCb+3uFRwSw3z8rnoeN2Jrec2BO +xIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=4ucyhqIdlPkmm1GLXkue1DXOIm83PMie+5RUllYQ/dI=; b=iX/O33TOHvCvMFF70anTDqpDIVJyAN5YCo6et9sILPj2aK6evpMDxYwik5DQCwoBYA iMLch2AFrB98Y460ktrmrENCdnZ0Mr9QGvpr33B3IrYjfOhMy1TzQ9wBcNbMPbihpGsm yjy7RW/QsBqbhCSDgo2baV4CncNkln06PKm7FMGFvecBQlavoEGVnl8dpkSZ4L3VE28/ pRp5dh5AfgFzD3xbIDVD4Qz5cMkidkMEBve78L56m32z/S2yAH9Ynr9sam3cqAEb2qar OBPCQhBi0+Yx/bZ72jxFM54QjbfAx28Ws0Dacue9nIJmRuQnSv7S9tqeGz6TeM3G3KVB OLXg== X-Gm-Message-State: AIkVDXJn9IHc+915A1+crig6BQrYCHe6GCoTIJaAsYugO8JkeS/dOH7OeSkoqSWoYnzjdA== X-Received: by 10.200.56.113 with SMTP id r46mr12597306qtb.217.1484923333526; Fri, 20 Jan 2017 06:42:13 -0800 (PST) Received: from [192.168.1.228] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id 7sm6053560qkx.49.2017.01.20.06.42.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Jan 2017 06:42:12 -0800 (PST) From: Ted Lemon Message-Id: <6B373B5B-C3EE-42A1-A9FF-3F371DAF64CE@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_80DEE7E4-6880-4D55-B678-918C04CBCA13" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Fri, 20 Jan 2017 09:42:11 -0500 In-Reply-To: <20170120.082215.74685531.sthaug@nethelp.no> To: "" References: <20170120.082215.74685531.sthaug@nethelp.no> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 14:42:16 -0000 --Apple-Mail=_80DEE7E4-6880-4D55-B678-918C04CBCA13 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jan 20, 2017, at 2:22 AM, sthaug@nethelp.no wrote: > Within a few minutes, I started seeing NTP traffic from the DHCP > clients. Checking the OUI of the MAC addresses I see a mix - both > typical "home router" vendors (e.g. Belkin), and also typical host > vendors (e.g. HP). Interesting=E2=80=94thanks for the hard data! The HP could be either a = printer or a host running Windows=E2=80=94might be interesting to see = which by looking at the DHCP lease. --Apple-Mail=_80DEE7E4-6880-4D55-B678-918C04CBCA13 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Jan 20, 2017, at 2:22 AM, sthaug@nethelp.no = wrote:
    Within a few minutes, I started seeing NTP = traffic from the DHCP
    clients. Checking the OUI of the MAC = addresses I see a mix - both
    typical "home router" vendors = (e.g. Belkin), and also typical host
    vendors (e.g. = HP).

    Interesting=E2=80=94thanks for the hard data!   The HP = could be either a printer or a host running Windows=E2=80=94might be = interesting to see which by looking at the DHCP lease.

    = --Apple-Mail=_80DEE7E4-6880-4D55-B678-918C04CBCA13-- From nobody Fri Jan 20 07:00:11 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 945EF1295BA for ; Fri, 20 Jan 2017 07:00:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=steffann.nl 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 E7wi2aB2G-ud for ; Fri, 20 Jan 2017 07:00:09 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:9e0:803::6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A25521295A9 for ; Fri, 20 Jan 2017 07:00:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 8278453; Fri, 20 Jan 2017 16:00:06 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:message-id:date:date:in-reply-to:from:from :subject:subject:mime-version:content-type:content-type:received :received; s=mail; t=1484924401; bh=jZdwXDDGZHxOIajUgShBTXFSbjOU tDFAZTSkFN3We2g=; b=WHG4ejALqITeCox6W1IuXN4/PlelFGlOun82F+VINn+u CtiMZApk+VndwPITrRKcpE2qRk6z4k222JhXj7K/x0fDygxoMx0EG8T7qNEowsKk jz2gmbmD7JdSHgr9es10S7tcxbmSQRvlyiF7pgzwh/lgY4D/i/N7fuk2kciJ/no= X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 1DL1pTjJuDAz; Fri, 20 Jan 2017 16:00:01 +0100 (CET) Received: from [IPv6:2a02:a213:a300:9300:885b:4d63:1e85:263a] (unknown [IPv6:2a02:a213:a300:9300:885b:4d63:1e85:263a]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.sintact.nl (Postfix) with ESMTPSA id 2410449; Fri, 20 Jan 2017 16:00:01 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_917DE44F-2B6E-4FB7-89D9-F53385AD26C3"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Clacks-Overhead: GNU Terry Pratchett From: Sander Steffann In-Reply-To: Date: Fri, 20 Jan 2017 16:00:00 +0100 Message-Id: <5A86DF1C-619A-42F9-892D-9254E3CBA5BE@steffann.nl> References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <99204933-5CB6-4E89-BD6A-FD40136DF6F5@steffann.nl> To: james woodyatt X-Mailer: Apple Mail (2.3124) Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 15:00:10 -0000 --Apple-Mail=_917DE44F-2B6E-4FB7-89D9-F53385AD26C3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi James, > Wait=E2=80=A6 what? >=20 > If there is a movement to load more options into RA Messages than = those necessary for providing hosts with DNS configuration even when = they don=E2=80=99t implement stateful DHCPv6, then I=E2=80=99d like to = have words with its leaders. There is no reasonable need for additional = service location information pushed in RA Messages beyond the DNS = servers and name search parameters because we have DNS-SD for providing = network parameters to hosts in general. DHCP may still be necessary for = providing some network operators with fine-grained centralized leasing = of network parameter configurations of individual specific hosts, but RA = Messages are more broadly required on most popular link layers, and they = should remain much much simpler to process. That was based on some comments I read in this thread about DHCPv6 not = being able to push changes to the devices the way that RA can, and only = being able to change settings when the client sends in a new request = (partially because DHCPv6 Reconfigure isn't widely implemented). > I see that I-D.v6ops-dhcpv6-slaac-problem doesn=E2=80=99t seem = confused about this point, so how did we arrive at this point in the = discussion? That was me extrapolating based on what I have seen on this list :) Cheers, Sander --Apple-Mail=_917DE44F-2B6E-4FB7-89D9-F53385AD26C3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJYgiXwAAoJEKAtA7D+JBO5w+0H/1UTaPLszWctLSh49sh8IUUd Vnn61gxxTwBu6v+xElBrheiPo3rlU9JbYzwlhvI9yL8UTsdrlgiJjbtegXnHHJZv HiqDgPgT0aPsAz6oYgViSmXJ/9+KXDhGrmb/RDwBzo5eThfN9Bvufl8JwMno9gqm XP3SHLygh/ToZBeCrAbTm1Co+lHkbM+vzTwnFi5h46+Y3v41r2IAhV6VMWEMLoMR xn7tByV3eN8V5zNaMZ6tYsiR66oDooo6wyOmcgVaZJTVinqSgZAneh3NpdzP5pU8 LIuZnfIwpFwCRkVixlbtPxpzSjz5iBaGeJRip56fv+11LfDWigbzAlHMpwyRqkE= =iF0x -----END PGP SIGNATURE----- --Apple-Mail=_917DE44F-2B6E-4FB7-89D9-F53385AD26C3-- From nobody Fri Jan 20 11:11:38 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 102321294A0 for ; Fri, 20 Jan 2017 11:11:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 H4_YqdirufEn for ; Fri, 20 Jan 2017 11:11:35 -0800 (PST) Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5525129458 for ; Fri, 20 Jan 2017 11:11:35 -0800 (PST) Received: by mail-pg0-x22c.google.com with SMTP id 14so25713522pgg.1 for ; Fri, 20 Jan 2017 11:11:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:message-id:mime-version:subject:date:references:to:in-reply-to; bh=PpjxB5Y0lQm7aS9uitefJSbYT8WfF+Ll+uHJzXOmZ/I=; b=DPFsTnsi4r9JNyRW99Es9Gqf5mpW6Dyw9WNuXCGrn7uQ2ZERpLHM8MnhkeljijOOfs yGBTJx5unbvlUwKZ9O9w+V4DSGsMnl3sSKpVSsT0BAOGSlTz8OH3CWcQRuoasAacy2VD NoXU3sSmQthy6D2PmfgaIBrBxCeQ2GHXMrl6EtaDBKzrwhMOuehnel0p448bnksJ7kCa Ifqz9G2f3hMy0phSbXJZ2de37Sh1NI9eyU2T7lPuitgsZL/BGvieW9a2Yxt6qSjgW673 o9CcGeC/AmxLqFE0ShvQYmNHDgT8V++HrzFOUwzY9YkyTpOvJlOVAqyohiNHqYkGQV6x c2NA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :references:to:in-reply-to; bh=PpjxB5Y0lQm7aS9uitefJSbYT8WfF+Ll+uHJzXOmZ/I=; b=o39Gw7SWkEHadpmT0OgLvxFGpdewobDXpNi/Y/VOXTfC/2BVcJ23cRVt/YZKqRkNYs 8inV8jfx/2/t6oPDn58M5ytbnplXCcVkPqHezj3AGPtwe0A7ZUOPpckH5OxO3ZVmU/Zg CASp1f43J7DjN+K1CRxNoLKUXZ6xsKiFfdU428qvKTLUQr9Agk4fyZo3EyyjWYHOYLg4 PUjn7fmSJn0DOEoFh+agCVdROCGeqpXTvshj51+hFO5POwMts9sN3bYWaRBRrqWaILJI EcFjfBfQNPznM6+nMVQopsezol2C5tWtXr+0iGuT3uflS9FseDtv40AUos4mhydVeYEi s4Rg== X-Gm-Message-State: AIkVDXKjc+92zKlWypCz/CpORHnBizX/id33zP81xzGnj7mYvrgFOQHlciAaBxFl43kcT9He X-Received: by 10.84.254.74 with SMTP id a10mr23607004pln.57.1484939494661; Fri, 20 Jan 2017 11:11:34 -0800 (PST) Received: from ?IPv6:2620::10e7:10:a426:fada:a43c:b55d? ([2620:0:10e7:10:a426:fada:a43c:b55d]) by smtp.gmail.com with ESMTPSA id z77sm18641195pfk.47.2017.01.20.11.11.33 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 20 Jan 2017 11:11:33 -0800 (PST) From: james woodyatt Content-Type: multipart/alternative; boundary="Apple-Mail=_869E2232-07FF-4F5B-AD1B-1D1C781D1392" Message-Id: <64592AC1-EFE9-4AA9-8C94-CF48986EC485@google.com> Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Date: Fri, 20 Jan 2017 11:11:38 -0800 References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <99204933-5CB6-4E89-BD6A-FD40136DF6F5@steffann.nl> To: IPv6 Ops WG In-Reply-To: X-Mailer: Apple Mail (2.3124) Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 19:11:37 -0000 --Apple-Mail=_869E2232-07FF-4F5B-AD1B-1D1C781D1392 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jan 19, 2017, at 20:46, Mikael Abrahamsson wrote: > On Thu, 19 Jan 2017, james woodyatt wrote: >>=20 >> [=E2=80=A6] leaders. There is no reasonable need for additional = service location information pushed in RA Messages beyond the DNS = servers and name search parameters because we have DNS-SD for providing = network parameters to >=20 > Errr, DNS-SD? What kind of network parameters are you talking about? I would have thought it clearly implied in context, but at the risk of = pedantry, I=E2=80=99ll be more explicit in the hope of providing more = clarity. I=E2=80=99m talking about the relatively small set of network parameters = currently distributed in operational practice by Stateless DHCP, along = with the considerably larger set that includes every other network = parameter currently distributed in operational practice by DNS-SD. Not = to mention all the parameters that could potentially be more easily = distributed=E2=80=94 to networks in general, rather than individually to = each host=E2=80=94 by DNS-SD than by DHCP due to its federated namespace = and globally distributed name service. --james woodyatt > --Apple-Mail=_869E2232-07FF-4F5B-AD1B-1D1C781D1392 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Jan 19, 2017, at 20:46, Mikael Abrahamsson <swmike@swm.pp.se> = wrote:
    On Thu, 19 Jan 2017, james woodyatt wrote:

    [=E2=80=A6] = leaders. There is no reasonable need for additional service location = information pushed in RA Messages beyond the DNS servers and name search = parameters because we have DNS-SD for providing network parameters to

    Errr, DNS-SD? What kind of = network parameters are you talking about?

    I would = have thought it clearly implied in context, but at the risk of pedantry, = I=E2=80=99ll be more explicit in the hope of providing more = clarity.

    I=E2=80=99m talking about = the relatively small set of network parameters currently distributed in = operational practice by Stateless DHCP, along with the considerably = larger set that includes every other network parameter currently = distributed in operational practice by DNS-SD. Not to mention all the = parameters that could potentially be more easily distributed=E2=80=94 to = networks in general, rather than individually to each host=E2=80=94 by = DNS-SD than by DHCP due to its federated namespace and globally = distributed name service.


    --james woodyatt <jhw@google.com>



    = --Apple-Mail=_869E2232-07FF-4F5B-AD1B-1D1C781D1392-- From jhw@google.com Fri Jan 20 11:14:56 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1CD11294AD for ; Fri, 20 Jan 2017 11:14:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 7mUghm5F32bZ for ; Fri, 20 Jan 2017 11:14:55 -0800 (PST) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EC7B1294A9 for ; Fri, 20 Jan 2017 11:14:55 -0800 (PST) Received: by mail-pf0-x236.google.com with SMTP id f144so24477229pfa.2 for ; Fri, 20 Jan 2017 11:14:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:message-id:mime-version:subject:date:references:to:in-reply-to; bh=JkrIkVHRoaid6MVRtMFlSDlxUeoaZ0EcrVRIvYty16s=; b=XDJ1O5MPVlVt1oq2ugd5pvBgVA+kcj6Ui5RSZCy9lL2GclTotwixIabW9LFN181M8d AZxcJgMOAtVdX1Oz2k6KwMdbrLrbZh++VW7m8I0mikW7nTDgO3y3sXvC6ls1U04kV4WD C46zVYXW5gyLgfpoHB/sjuJhTgO+UzIg0BD/8mLb6LY/JwS+l91Ws7TgrXjeongt0Sue Dhl3S2uDf7r2+WM8TpRdWD7bPA2d1sJqVsxu1w/7xpYnYP1t952Nm0B7ySqQThattgMI tCJtCFPOH3aS+8cyn7dnsu5iO0sRuiaho+IUnogNgB/LsmdlJWe3OAuA6oJ7egCthIjs XWKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :references:to:in-reply-to; bh=JkrIkVHRoaid6MVRtMFlSDlxUeoaZ0EcrVRIvYty16s=; b=D9uGZfXvKDMe8V343jzoeOAEcW6yaHqFcTrqT1peJhzjcQ6MxFO0r7cjX4u7l2Kmmv bmjRgXSwvM73DWVcCGVX8axIH3ot4w1p5xM7JT65aW2VGtAJQRsqVPmHwRPboPeO6OSs WU/rZmPsVzz4dxRx6/b/25TbwYXSalNoy1/emkgLoP0vLbYoiqOjCRu1sQmCjjcC67Dy sNum4UTlNDbymeZgAddrLrTx994vOvmRsayu9PFMOxEtT3bFL1LGF03orSnlcINhdaHu tzl22ZwvZQQ1OkHVrQF+308j33suKPvThDQfzf2AkI3mvKiwfaFaOmYb6PwZk9I0bQQ1 2znA== X-Gm-Message-State: AIkVDXLBHNPhNYjofDwQ7KE4xykOZgANUGDbjjCetEttLFKg3zmiPa3o1vKJIothv64bMXTy X-Received: by 10.84.167.2 with SMTP id c2mr23280691plb.56.1484939694516; Fri, 20 Jan 2017 11:14:54 -0800 (PST) Received: from ?IPv6:2620::10e7:10:a426:fada:a43c:b55d? ([2620:0:10e7:10:a426:fada:a43c:b55d]) by smtp.gmail.com with ESMTPSA id y6sm18779144pge.16.2017.01.20.11.14.53 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 20 Jan 2017 11:14:53 -0800 (PST) From: james woodyatt Content-Type: multipart/alternative; boundary="Apple-Mail=_D4568DE8-69A4-425A-A3E7-F0CA228CB960" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Date: Fri, 20 Jan 2017 11:14:58 -0800 References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <99204933-5CB6-4E89-BD6A-FD40136DF6F5@steffann.nl> To: IPv6 Ops WG In-Reply-To: X-Mailer: Apple Mail (2.3124) Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 19:14:57 -0000 --Apple-Mail=_D4568DE8-69A4-425A-A3E7-F0CA228CB960 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jan 19, 2017, at 20:46, Mikael Abrahamsson wrote: > On Thu, 19 Jan 2017, james woodyatt wrote: >>=20 >> If there is a movement to load more options into RA Messages than = those necessary for providing hosts with DNS configuration even when = they >=20 > In order to make DNSSEC validation work, there might be a need to put = NTP server in RA as well. As noted, I=E2=80=99m skeptical about that one. > There are other options that have gone into RA lately, that probably = hasn't been widely noticed. For instance there is a captive portal = option for RA. It escaped my attention until now. I=E2=80=99m at a loss to understand = how that happened. I=E2=80=99m sure there must have been a contentious = debate in 6MAN that I completely missed. --james woodyatt > --Apple-Mail=_D4568DE8-69A4-425A-A3E7-F0CA228CB960 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Jan 19, 2017, at 20:46, Mikael Abrahamsson <swmike@swm.pp.se> = wrote:
    On Thu, 19 Jan 2017, james woodyatt wrote:

    If there is = a movement to load more options into RA Messages than those necessary = for providing hosts with DNS configuration even when they

    In order to make DNSSEC = validation work, there might be a need to put NTP server in RA as = well.

    As noted, I=E2=80=99m skeptical about that = one.

    There are other options that have gone into = RA lately, that probably hasn't been widely noticed. For instance there = is a captive portal option for RA.

    It = escaped my attention until now. I=E2=80=99m at a loss to understand how = that happened. I=E2=80=99m sure there must have been a contentious = debate in 6MAN that I completely missed.


    --james woodyatt <jhw@google.com>



    = --Apple-Mail=_D4568DE8-69A4-425A-A3E7-F0CA228CB960-- From nobody Fri Jan 20 12:49:02 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA32B12944D for ; Fri, 20 Jan 2017 12:49:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 j08eqwziTesD for ; Fri, 20 Jan 2017 12:48:59 -0800 (PST) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89F4112944F for ; Fri, 20 Jan 2017 12:48:59 -0800 (PST) Received: by mail-vk0-x229.google.com with SMTP id x75so57657750vke.2 for ; Fri, 20 Jan 2017 12:48:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/wS2q9UzcdTErWibOXWUN2h5X5sIA8npQOJpB/Gi10k=; b=QEpIpIN6/XachIQeQVBzawr/m/7UELvrnqVhzBU+dUjJsox+VIWwAr22cL5uzTHZLj C7EnybenQ2kJUNftsUzbmhaJWLUzMqXwhpi+ZDeyGx2ffNBcrRlA92lQ7yAUc6WH58py 9thqejdK5hQqLO3So1oTf19Vy09Nc9R65xkYdTRfS+19iMsvH5w1P0rHQO8FpmMIg6BP XxHJIHQKDx5rfo4ERz/nNiQHS2PR8thWXqoCjTjzvV0ANCRCCd6MqR5/odZwI0+G2zaI dGn8mfpkN4gnX4m0jpRJ5trdthy/BTnatEMpabzNKARxRMyAyQYmTi16v2i50MvNnpPn ncPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/wS2q9UzcdTErWibOXWUN2h5X5sIA8npQOJpB/Gi10k=; b=K+Kp471Lm8PnoIh7yWr6jcaBsDmcJbfduELcNvWyk3QVmp/UW/9UXrWSCys5+zq7t7 OnSlgBByDuOjRG2r0R8fopfbvltuRI2XXkQ6U1d78sbpmk9JZ0Fa4W3aW1QXlvM5GZg7 FERpoDpp6Z/iVCTr7qixdzcJzCvmEdRH8P7UqBuFJFY7fzY9rSGk0cIWWVgmrKcM5FnG lrDD8zvij7U3IZhxP4ZncKrwX+RSRknYx8L2oakOgACfZtrA63acDwE06mTwZA1GrIAR gqQ/WU4koVzGfXjJZ6GAJGnNmgKg82m9ZXLqT+mwH4cZIqMIaRXz0uQW1A3D3qy+DPCt 5sMw== X-Gm-Message-State: AIkVDXKU+HzaTaZ+bcJWgplTdYCzw90DB48hahEYe13Ns9P5PdeTYG9T0sbaVkt6p5Id6c5qlejCR1+AaxNs7g== X-Received: by 10.31.79.132 with SMTP id d126mr7874589vkb.165.1484945338691; Fri, 20 Jan 2017 12:48:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.2.235 with HTTP; Fri, 20 Jan 2017 12:48:58 -0800 (PST) Received: by 10.176.2.235 with HTTP; Fri, 20 Jan 2017 12:48:58 -0800 (PST) In-Reply-To: References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <99204933-5CB6-4E89-BD6A-FD40136DF6F5@steffann.nl> From: Mark Smith Date: Sat, 21 Jan 2017 07:48:58 +1100 Message-ID: To: james woodyatt Content-Type: multipart/alternative; boundary=001a114dd4cc6c761f05468cc756 Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 20:49:01 -0000 --001a114dd4cc6c761f05468cc756 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 21 Jan. 2017 06:15, "james woodyatt" wrote: On Jan 19, 2017, at 20:46, Mikael Abrahamsson wrote: On Thu, 19 Jan 2017, james woodyatt wrote: If there is a movement to load more options into RA Messages than those necessary for providing hosts with DNS configuration even when they In order to make DNSSEC validation work, there might be a need to put NTP server in RA as well. As noted, I=E2=80=99m skeptical about that one. There are other options that have gone into RA lately, that probably hasn't been widely noticed. For instance there is a captive portal option for RA. It escaped my attention until now. I=E2=80=99m at a loss to understand how = that happened. I=E2=80=99m sure there must have been a contentious debate in 6MA= N that I completely missed. I'm pretty sure I objected to the idea of using RA options for this. I'm starting to accept that people don't have a problem with upgrading router firmware every time they need to deploy a new application or application related feature. I think this is the antithesis of the Internet payload oblivious dumb network, smart hosts model, however there are perverse incentives to create or to ignore creation of more operational work. Regards, Mark. --james woodyatt _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops --001a114dd4cc6c761f05468cc756 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


    On 21 Jan. 2017 06:15, "james woodyatt" <jhw@google.com> wrote:

    <= /div>






    <= /div>

    _______________________________________________
    v6ops mailing list
    v6ops@ietf.org
    https://www.ietf.org/mailman/listinfo/v6ops


    --001a114dd4cc6c761f05468cc756-- From nobody Fri Jan 20 19:12:26 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 056761296A2 for ; Fri, 20 Jan 2017 19:12:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.5 X-Spam-Level: X-Spam-Status: No, score=-7.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se 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 q8_UgjCWa5D0 for ; Fri, 20 Jan 2017 19:12:24 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B2CF129691 for ; Fri, 20 Jan 2017 19:12:24 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 25DF8A3; Sat, 21 Jan 2017 04:12:22 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1484968342; bh=PfYBZggG8ZEaN6Icgw9uu5xor6Cpsyinn8ISz91etl4=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=AtCnFTJJe+mfUtkDqqoNbXChM5OfuRWzjGv7mMVSLT/wAkrR6WR4K+YLtv49oCKDv ypyXSJietlkf0gS97TRQxHnPcB3vLKbrJJF6ddfbIy6L1cgUODIHehTYZnpA4vsAcd fS2l80ST8ZLwxMxdlb1fEvBCfRzWIBC+AyFWA9wY= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 204D1A2; Sat, 21 Jan 2017 04:12:22 +0100 (CET) Date: Sat, 21 Jan 2017 04:12:22 +0100 (CET) From: Mikael Abrahamsson To: james woodyatt In-Reply-To: <64592AC1-EFE9-4AA9-8C94-CF48986EC485@google.com> Message-ID: References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <99204933-5CB6-4E89-BD6A-FD40136DF6F5@steffann.nl> <64592AC1-EFE9-4AA9-8C94-CF48986EC485@google.com> 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-1731137473-1484968342=:31101" Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jan 2017 03:12:26 -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-1731137473-1484968342=:31101 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT On Fri, 20 Jan 2017, james woodyatt wrote: > I would have thought it clearly implied in context, but at the risk of > pedantry, I’ll be more explicit in the hope of providing more clarity. Please do. > I’m talking about the relatively small set of network parameters > currently distributed in operational practice by Stateless DHCP, along > with the considerably larger set that includes every other network > parameter currently distributed in operational practice by DNS-SD. Not > to mention all the parameters that could potentially be more easily > distributed— to networks in general, rather than individually to each > host— by DNS-SD than by DHCP due to its federated namespace and globally > distributed name service. I am still left guessing here. DNS-resolver? Search domain? NTP server? TFTP server? MTU? I wasn't even aware that DNS-SD would do these things, that's why I'm still trying to figure out what you're saying and what you're proposing. It sounded to me that you said that you wanted DNS-SD to handle a lot of these tasks? -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-1731137473-1484968342=:31101-- From nobody Fri Jan 20 19:14:54 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BBC41296A7 for ; Fri, 20 Jan 2017 19:14:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 lEQY43oLK7F9 for ; Fri, 20 Jan 2017 19:14:51 -0800 (PST) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78B631296A6 for ; Fri, 20 Jan 2017 19:14:51 -0800 (PST) Received: by mail-qk0-x22e.google.com with SMTP id u25so29958981qki.2 for ; Fri, 20 Jan 2017 19:14:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=FYwt06iM3eLjTeO/pDzX3X+kTuS281eiPGCJ/PNQ3pg=; b=hAyB/+4mUIXNqrE2JA8tjifuEMr0t9zODHMEOnhchUflu4VIbkVJt37lKdimjwuYyG kCgylESi5LJoQiw8uanaI0+BeASxPDz3aDArSTi9vSVgCNSL80JYLWIix68XXdlAJin6 yJZmi7oX8UCtHIIasQf1hr+r/A/lfizl/Sb7G2B7yoUkz9EB5bBWHqTq6m9/I7exjRdH rATrg8KUgrjGvkexfdIQYVILnqA2Ue6qPCrI4Rnwg+q9A7wycEpFffSY3DwwMcLxxAWi 5pRIZW4rdn4uE0igTJFdyK+AkAUuBkycUFgE18pDOAFfez6+DJiso1U70qxzjTi/71zX /wTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=FYwt06iM3eLjTeO/pDzX3X+kTuS281eiPGCJ/PNQ3pg=; b=loL2FV+7G0qmWMm1DpxSjbpf+Q/qDCKMAVK3OqPEraNvWk8vfbsVy2xWgrw91hyg2c GSJT+3VJns/w/HVQmcfrmUdgYO0CtHuWV0SglPkRcxpspJrn+Rllnz7gdgcr3UzmbjNc ExJUWmApmqJd1SvWwZlS0cuJOtwzyk4Hsb899AYttKewdb1EUBMcDG1zSxjWFYkNwmcJ I2TRYMCuo2uV4lpYzyb4XYtAEqEuuK41iubKDJfPCWz+2VXLfTD1c8PD4F5xFLBGAxKF 7fT9kWCQbN+ftMdk3+FrwPNwoP9eDiihAn42S0WFToxXX7e99HO17VqG1x9pk9qmDKyc suQA== X-Gm-Message-State: AIkVDXIy+QnYPgHbKmF46JpjdvsdG7Itl0OD+FmxdwlzJNWswn2Zcg9QOlnSUVtrRWNoFw== X-Received: by 10.55.45.129 with SMTP id t123mr14668456qkh.311.1484968490583; Fri, 20 Jan 2017 19:14:50 -0800 (PST) Received: from [192.168.1.228] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id z8sm6673233qkz.42.2017.01.20.19.14.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Jan 2017 19:14:49 -0800 (PST) From: Ted Lemon Message-Id: <892E650B-5F77-4FB9-B157-B84300E15CF6@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E7DBE19C-632D-4EA4-8A2D-8AA0BCE8DB4A" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Fri, 20 Jan 2017 22:14:46 -0500 In-Reply-To: To: Mikael Abrahamsson References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <99204933-5CB6-4E89-BD6A-FD40136DF6F5@steffann.nl> <64592AC1-EFE9-4AA9-8C94-CF48986EC485@google.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: james woodyatt , IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jan 2017 03:14:53 -0000 --Apple-Mail=_E7DBE19C-632D-4EA4-8A2D-8AA0BCE8DB4A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jan 20, 2017, at 10:12 PM, Mikael Abrahamsson = wrote: > I wasn't even aware that DNS-SD would do these things, that's why I'm = still trying to figure out what you're saying and what you're proposing. = It sounded to me that you said that you wanted DNS-SD to handle a lot of = these tasks? DNS-SD can't deliver you a resolver, since in its non-mDNS form, it = requires you to already know how to contact the resolver. So no, you = can't configure DNS using DNS-SD. --Apple-Mail=_E7DBE19C-632D-4EA4-8A2D-8AA0BCE8DB4A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Jan 20, 2017, at 10:12 PM, Mikael Abrahamsson <swmike@swm.pp.se> = wrote:
    I wasn't even aware that DNS-SD would do these = things, that's why I'm still trying to figure out what you're saying and = what you're proposing. It sounded to me that you said that you wanted = DNS-SD to handle a lot of these tasks?

    DNS-SD can't deliver you a resolver, since in its non-mDNS = form, it requires you to already know how to contact the resolver. =   So no, you can't configure DNS using DNS-SD.

    = --Apple-Mail=_E7DBE19C-632D-4EA4-8A2D-8AA0BCE8DB4A-- From nobody Sat Jan 21 01:02:41 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D446C12944C for ; Sat, 21 Jan 2017 01:02:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.799 X-Spam-Level: X-Spam-Status: No, score=-5.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=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 PFpD9iz3jbrG for ; Sat, 21 Jan 2017 01:02:38 -0800 (PST) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F8D41270B4 for ; Sat, 21 Jan 2017 01:02:37 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 22698614C7 for ; Sat, 21 Jan 2017 10:02:34 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 388F7604B9; Sat, 21 Jan 2017 10:02:33 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id 17A3F2777A; Sat, 21 Jan 2017 10:02:33 +0100 (CET) Date: Sat, 21 Jan 2017 10:02:33 +0100 From: Gert Doering To: Brian E Carpenter Message-ID: <20170121090232.GB48971@Space.Net> References: <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <99204933-5CB6-4E89-BD6A-FD40136DF6F5@steffann.nl> <3ebea184-926c-8c2a-bf8c-cf6514874821@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3ebea184-926c-8c2a-bf8c-cf6514874821@gmail.com> X-NCC-RegID: de.space User-Agent: Mutt/1.7.1 (2016-10-04) Archived-At: Cc: james woodyatt , IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jan 2017 09:02:40 -0000 Hi, On Fri, Jan 20, 2017 at 03:47:24PM +1300, Brian E Carpenter wrote: > On 20/01/2017 08:43, Mark Smith wrote: > ... > > Brian has said RDNSS was aimed less resource constrained environments > > such as cafes, homes etc. Unfortunately that doesn't seem to be that > > clear, as much larger organisations are seeming to see it as the > > general purpose way of deploying DNS parameters... > > Could that possibly be because DHCPv6 doesn't support next-hop router > advertisements, and they know that all hosts need both a DNS server > and a next-hop router? And for most hosts, that's *all* they need > once they have an address. > > It isn't the first time in IETF history that a protocol feature has > been used for unexpected purposes. I wouldn't call that "unexpected" - personally, I thought that was the point all along: SLAAC with all relevant information, namely "IPv6 address, gateway, DNS servers". Everything else is nice, but without DNS, you need an extra protocol to provision those - so in my view, adding RDNSS was fixing a glaring omission in RA. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Sat Jan 21 03:57:04 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC4D31299BA for ; Sat, 21 Jan 2017 03:57:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=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 y4TTrEQUUQbU for ; Sat, 21 Jan 2017 03:57:00 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 97AFC1299B7 for ; Sat, 21 Jan 2017 03:56:57 -0800 (PST) Received: from stereo.hq.phicoh.net ([::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #127) id m1cUuHv-0000ISC; Sat, 21 Jan 2017 12:56:55 +0100 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bF054DD66@u-1.phicoh.com References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <99204933-5CB6-4E89-BD6A-FD40136DF6F5@steffann.nl> <64592AC1-EFE9-4AA9-8C94-CF48986EC485@google.com> <892E650B-5F77-4FB9-B157-B84300E15CF6@fugue.com> In-reply-to: Your message of "Fri, 20 Jan 2017 22:14:46 -0500 ." <892E650B-5F77-4FB9-B157-B84300E15CF6@fugue.com> Date: Sat, 21 Jan 2017 12:56:53 +0100 Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jan 2017 11:57:01 -0000 >DNS-SD can't deliver you a resolver, since in its non-mDNS form, it >requires you to already know how to contact the resolver. So no, you >can't configure DNS using DNS-SD. I assume you can just do a mDNS lookup for _dns._udp.local. Of course, if the DNS-SD information is in public DNS, then you can just as well use any global resolver, like 2001:4860:4860::8888 (I almost typed 8.8.8.8). The one thing you can't get is the search domain. Though of course that could be encoded as a TXT record in the relevant DNS resolver pointed to by _dns._udp.local. The one thing that is possible in DHCP and almost impossible in any of the alternatives (RA, DNS-SD) is configuration that varies per host. Some of the classical DHCP options, like hostname, root path, boot file name, are host specific. It seems that the one thing that was left out of DNS-SD is support for host specific configuration. I guess it should be easy enough to put in. From nobody Sat Jan 21 07:57:31 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7064129A95 for ; Sat, 21 Jan 2017 07:57:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 hkOY96kux7AP for ; Sat, 21 Jan 2017 07:57:28 -0800 (PST) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 556FD129B20 for ; Sat, 21 Jan 2017 07:57:28 -0800 (PST) Received: by mail-qt0-x22c.google.com with SMTP id v23so71042322qtb.0 for ; Sat, 21 Jan 2017 07:57:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=QPa7L0hWRPto8NkXPP79FylahlEF0auJfDzfd87SSvc=; b=Z8AFXOkawzDA8XreSI7FV3gKpb+DfqNbjDbgn9JPEtgEeRrgFSwRrY++XJUO7zDzNG ofZZ+kttrLGXt3Grry9O5QVKKIUexXGZo2RMR9SKtBxgYdKG0GJOpcxeHUbDXdfjAkIW Qpz5Dg90syACH9oivKCdaYr4Pkh3PXu96QvoRk7zETfgFy0NFTipzQff4s6StXcKnlH8 HMup0EXwKzcS88mdNCqrWGSh/Co1UD6+x2aM/nE2jH+bHm/N1iNdlos4DbAi9/BmgOQ4 IVnzyiDMEZWE93QAys3xY+qNmE3BHWlr89n/8P/bpw0vLg5XNDfjb/MTGMMtVWSjVQiC n7SQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=QPa7L0hWRPto8NkXPP79FylahlEF0auJfDzfd87SSvc=; b=G7ydhk9Zb8p0KSKB51awOzecb03UV2B4YEZx+jXgrHoj7H+DZxQuXTn0j4DV3CZeYy BA91oJEKQklDPkHmJAxoxyebWEpM/asj3/dlt1KBw7eXY4FWyYXL6+QtEVsNzCi02fA7 yKS51xjEgKgCBtQzqGr44B4BOvPRg0jasZhuDxpFAV+9oaNJLk5ix5Q2ui5S6nH7X0h4 KdPF4uOruVCoChbCtiHNmYgVExFpEZt7ut++jq/FERpLJNCllmjHniY1W/pvCMMbD2X9 rmAoEna178M/Srk0R28LjjsEnMFk4WsV3siD7JhwRzL965iYKIhkz/5IfEgEIBqyQY0q H1eg== X-Gm-Message-State: AIkVDXKHCBj7ZEb05u2kNBMMS5Qr/xHxW8j19kJOqLLYzl5+Rb14fWmDUcPuIb1Gl3kBeg== X-Received: by 10.237.36.166 with SMTP id t35mr16695435qtc.172.1485014247290; Sat, 21 Jan 2017 07:57:27 -0800 (PST) Received: from [10.0.20.229] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id k18sm5081618qtc.12.2017.01.21.07.57.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 21 Jan 2017 07:57:25 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ted Lemon In-Reply-To: Date: Sat, 21 Jan 2017 10:57:23 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <99204933-5CB6-4E89-BD6A-FD40136DF6F5@steffann.nl> <64592AC1-EFE9-4AA9-8C94-CF48986EC485@google.com> <892E650B-5F77-4FB9-B157-B84300E15CF6@fugue.com> To: Philip Homburg X-Mailer: Apple Mail (2.3259) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jan 2017 15:57:30 -0000 On Jan 21, 2017, at 6:56 AM, Philip Homburg = wrote: > I assume you can just do a mDNS lookup for _dns._udp.local. Only if there is a server listening for such lookups on the local wire. > Of course, if the DNS-SD information is in public DNS, then you can = just > as well use any global resolver, like 2001:4860:4860::8888 (I almost > typed 8.8.8.8). Yes, that definitely won't work in most cases, because as you suggest, = the information is not actually public (and may not even be in a = fully-functional DNS zone). > The one thing you can't get is the search domain. Though of course > that could be encoded as a TXT record in the relevant DNS resolver = pointed > to by _dns._udp.local. Search domain is an attack surface. So this would actually be a win. > The one thing that is possible in DHCP and almost impossible in any of = the > alternatives (RA, DNS-SD) is configuration that varies per host. Some = of > the classical DHCP options, like hostname, root path, boot file > name, are host specific. ND has host-specific configuration. But boot service is actually = precisely what DHCP is best at. > It seems that the one thing that was left out of DNS-SD is support for > host specific configuration. I guess it should be easy enough to put = in. I suspect that it would be impossible without extensions, since the = server doesn't have a client identifier to check. I suppose the client = could send an EDNS0 option with an identifier, but it seems silly to go = to the trouble when DHCP already solves this problem. From nobody Sat Jan 21 08:36:55 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6750C129B4C for ; Sat, 21 Jan 2017 08:36:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=steffann.nl 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 ENVK9BLmqb02 for ; Sat, 21 Jan 2017 08:36:52 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:9e0:803::6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9048A129B47 for ; Sat, 21 Jan 2017 08:36:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 491F149; Sat, 21 Jan 2017 17:36:50 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:message-id:date:date:in-reply-to:from:from :subject:subject:mime-version:content-type:content-type:received :received; s=mail; t=1485016608; bh=lMVIHKqeZ55VW9pJzF1pgNT6saID QCuxXsxn2x+pWfQ=; b=TgkU5IbVH3YVda9xmXLj5WuZgCw3AZL4iuBa2aW+FCIF EvehNylx8OtX4ytEIfRpwuPVk7Q8SIW8xj1DCOt4GRyEASh/rw3ej1M6dLn5Qcbg 6giPce94/MseyWrgBMPo/emNQP7q73fcCBOqqkwaNHY7qTCElCCfwgRkRQpo0Fw= X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ZjE-ZLpVwFsQ; Sat, 21 Jan 2017 17:36:48 +0100 (CET) Received: from [IPv6:2a02:a213:a300:9300:9455:df43:fe17:5717] (unknown [IPv6:2a02:a213:a300:9300:9455:df43:fe17:5717]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.sintact.nl (Postfix) with ESMTPSA id 6942F48; Sat, 21 Jan 2017 17:36:48 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_E52DD479-C8AB-499D-9863-5CD2A37E3B70"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Clacks-Overhead: GNU Terry Pratchett From: Sander Steffann In-Reply-To: Date: Sat, 21 Jan 2017 17:36:48 +0100 Message-Id: <022959E8-224B-447D-A844-17C20FA5A42E@steffann.nl> References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <99204933-5CB6-4E89-BD6A-FD40136DF6F5@steffann.nl> <64592AC1-EFE9-4AA9-8C94-CF48986EC485@google.com> <892E650B-5F77-4FB9-B157-B84300E15CF6@fugue.com> To: Ted Lemon X-Mailer: Apple Mail (2.3124) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jan 2017 16:36:54 -0000 --Apple-Mail=_E52DD479-C8AB-499D-9863-5CD2A37E3B70 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, >> The one thing that is possible in DHCP and almost impossible in any = of the >> alternatives (RA, DNS-SD) is configuration that varies per host. Some = of >> the classical DHCP options, like hostname, root path, boot file >> name, are host specific. >=20 > ND has host-specific configuration. But boot service is actually = precisely what DHCP is best at. >=20 >> It seems that the one thing that was left out of DNS-SD is support = for >> host specific configuration. I guess it should be easy enough to put = in. >=20 > I suspect that it would be impossible without extensions, since the = server doesn't have a client identifier to check. I suppose the client = could send an EDNS0 option with an identifier, but it seems silly to go = to the trouble when DHCP already solves this problem. I'm getting confused... There seem to be too many different = configuration mechanisms to keep a coherent model in my mind. What is = supposed to go where? We have RA for layer-3 options and DNS, for a bare = minimum network configuration. Then we have DHCPv6 both stateless = (layer-4+ IPv6, and some layer-3 IPv4 stuff like DS-Lite and MAP) = stateful (with additional layer-3 IPv6 options). And then we have DNS-SD = with even more options. All of these also have different push and pull models. I give a lot of IPv6 training, and I'm struggling with how to explain to = my IPv6-newbie students how this all fits together... It all comes back = to the problem for most network admins that IPv6 provides a lot of cool = features, but the number of possible combinations is so large that they = don't know what to do anymore. The learning curve for understanding all = the options and protocols and possible combination is getting so steep = that it's becoming a barrier to less experienced network admins... I hope someone can give me a clear picture of what the intended = architecture behind all these protocols is. Cheers, Sander --Apple-Mail=_E52DD479-C8AB-499D-9863-5CD2A37E3B70 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJYg44gAAoJEKAtA7D+JBO5NssH/RWGrV32JaukuR7GcpMakZXQ 3dfq3yXTWZjZuD0LcZLnRSzIj527e5NO82W0PcHwbJwKe3jkKJWf4/OV8g7tOL+p Mgt7sBqD9DYf3H6c7O5J3l+jtNkvB2uq2Hc3w2gzEnejrCEh4AFLR68dLL+NMe64 k64KpROwFocDfbbH7lJvaog1aUfQdbo8YYJGLcPRWIis8duimyV+NdFXCDaeq61D u/iOW9SktWiaA7y1QdCxz3Eqb3I0sGG8CJt1wq8NZT4v4IhaVPBfgBSTXoy3qCES xN28y6hqXZ/qFdl59p7dADUreI24hpnO2IRQHSkjQeZLye8GxlCaKBknF5350pM= =AD7n -----END PGP SIGNATURE----- --Apple-Mail=_E52DD479-C8AB-499D-9863-5CD2A37E3B70-- From nobody Sat Jan 21 11:43:27 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D0F7129C27 for ; Sat, 21 Jan 2017 11:43:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=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 J4DlDrxQqmUq for ; Sat, 21 Jan 2017 11:43:25 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 800D1129B4C for ; Sat, 21 Jan 2017 11:43:22 -0800 (PST) Received: from stereo.hq.phicoh.net ([::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #127) id m1cV1ZI-0000H9C; Sat, 21 Jan 2017 20:43:20 +0100 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bF054DD66@u-1.phicoh.com References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <99204933-5CB6-4E89-BD6A-FD40136DF6F5@steffann.nl> <64592AC1-EFE9-4AA9-8C94-CF48986EC485@google.com> <892E650B-5F77-4FB9-B157-B84300E15CF6@fugue.com> In-reply-to: Your message of "Sat, 21 Jan 2017 10:57:23 -0500 ." Date: Sat, 21 Jan 2017 20:43:18 +0100 Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jan 2017 19:43:26 -0000 >> Of course, if the DNS-SD information is in public DNS, then you can = >just >> as well use any global resolver, like 2001:4860:4860::8888 (I almost >> typed 8.8.8.8). > >Yes, that definitely won't work in most cases, because as you suggest, >the information is not actually public (and may not even be in a >fully-functional DNS zone). I wonder how this is supposed to work (I have no experience with DNS-SD). Suppose a laptop is set to use 8.8.8.8 because in some locations the advertised DNS resolver is weird. Would that break DNS-SD in other locations. And if so, would the user figure out why it doesn't work? >ND has host-specific configuration. How does that work? One of the reasons to have a default router in DHCPv6 is to give some hosts a different default router. As far as I know there are no specifications on how to send unique RAs to individual hosts. Technically you can send RAs using unicast. But there doesn't seem to be the equivalent of a DUID in an RS. >> It seems that the one thing that was left out of DNS-SD is support for >> host specific configuration. I guess it should be easy enough to put = >in. > >I suspect that it would be impossible without extensions, since the >server doesn't have a client identifier to check. I suppose the client >could send an EDNS0 option with an identifier, but it seems silly to go >to the trouble when DHCP already solves this problem. What i was thinking of as a simple extension is before looking up . look for ... Using the same DUID as in DHCP should make it easy to mix and match. This requires no server side changes. But does of course require client side changes. From nobody Sat Jan 21 11:56:07 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4BDE129C54 for ; Sat, 21 Jan 2017 11:56:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=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 DbMDe2NJFbp2 for ; Sat, 21 Jan 2017 11:56:05 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id A5A72129C53 for ; Sat, 21 Jan 2017 11:56:04 -0800 (PST) Received: from stereo.hq.phicoh.net ([::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #127) id m1cV1lb-0000FjC; Sat, 21 Jan 2017 20:56:03 +0100 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bF054DD66@u-1.phicoh.com References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <99204933-5CB6-4E89-BD6A-FD40136DF6F5@steffann.nl> <64592AC1-EFE9-4AA9-8C94-CF48986EC485@google.com> <892E650B-5F77-4FB9-B157-B84300E15CF6@fugue.com> <022959E8-224B-447D-A844-17C20FA5A42E@steffann.nl> In-reply-to: Your message of "Sat, 21 Jan 2017 17:36:48 +0100 ." <022959E8-224B-447D-A844-17C20FA5A42E@steffann.nl> Date: Sat, 21 Jan 2017 20:56:03 +0100 Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jan 2017 19:56:06 -0000 >I'm getting confused... There seem to be too many different >configuration mechanisms to keep a coherent model in my mind. What is >supposed to go where? We have RA for layer-3 options and DNS, for a bare >minimum network configuration. Then we have DHCPv6 both stateless >(layer-4+ IPv6, and some layer-3 IPv4 stuff like DS-Lite and MAP) >stateful (with additional layer-3 IPv6 options). And then we have DNS-SD >with even more options. It seems that after the age of too many almost but not quite similar transition technologies, we are now entering the age of configuration technologies. For Homenet, there is HNCP as well. From nobody Sat Jan 21 13:13:52 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFB891293E8 for ; Sat, 21 Jan 2017 13:13:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.099 X-Spam-Level: X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=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 9Rti-V_-8K7w for ; Sat, 21 Jan 2017 13:13:48 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4535D1293F3 for ; Sat, 21 Jan 2017 13:13:48 -0800 (PST) Received: from mbp-4.local ([IPv6:2601:647:4201:9e61:3daa:dfa8:3d1b:9b0]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id v0LLDkRM049415 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Sat, 21 Jan 2017 21:13:47 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host [IPv6:2601:647:4201:9e61:3daa:dfa8:3d1b:9b0] claimed to be mbp-4.local To: Philip Homburg , v6ops@ietf.org References: <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <99204933-5CB6-4E89-BD6A-FD40136DF6F5@steffann.nl> <64592AC1-EFE9-4AA9-8C94-CF48986EC485@google.com> <892E650B-5F77-4FB9-B157-B84300E15CF6@fugue.com> <022959E8-224B-447D-A844-17C20FA5A42E@steffann.nl> From: joel jaeggli Message-ID: <25486c7b-8600-d3ed-3a9f-013388f8d947@bogus.com> Date: Sat, 21 Jan 2017 13:13:46 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wdCtl1hcxeP3rAoVV0jw7e2XwFccehfge" Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jan 2017 21:13:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wdCtl1hcxeP3rAoVV0jw7e2XwFccehfge Content-Type: multipart/mixed; boundary="nrV5pXGjFVoU6l38rvvPQXBnjlh5DuKQC"; protected-headers="v1" From: joel jaeggli To: Philip Homburg , v6ops@ietf.org Message-ID: <25486c7b-8600-d3ed-3a9f-013388f8d947@bogus.com> Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <99204933-5CB6-4E89-BD6A-FD40136DF6F5@steffann.nl> <64592AC1-EFE9-4AA9-8C94-CF48986EC485@google.com> <892E650B-5F77-4FB9-B157-B84300E15CF6@fugue.com> <022959E8-224B-447D-A844-17C20FA5A42E@steffann.nl> In-Reply-To: --nrV5pXGjFVoU6l38rvvPQXBnjlh5DuKQC Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 1/21/17 11:56 AM, Philip Homburg wrote: >> I'm getting confused... There seem to be too many different=20 >> configuration mechanisms to keep a coherent model in my mind. What is = >> supposed to go where? We have RA for layer-3 options and DNS, for a ba= re=20 >> minimum network configuration. Then we have DHCPv6 both stateless=20 >> (layer-4+ IPv6, and some layer-3 IPv4 stuff like DS-Lite and MAP)=20 >> stateful (with additional layer-3 IPv6 options). And then we have DNS-= SD=20 >> with even more options. > It seems that after the age of too many almost but not quite similar > transition technologies, we are now entering the age of configuration=20 > technologies. > > For Homenet, there is HNCP as well.=20 this isn't really that different then the way things were in the ancien regime . Back in 1995 or so bootp and dhcp (and slaac) were never (and are not now) expressive enough to provide anything other than the barest device configuration. so the first thing you do once you've got a network configuration, is you tftp a config, contact an ldap server, or otherwise engage some upper layer device management (standardized or not) to get the rest of your network or device communication. the profusion of ways and places this can be done points to a lack of a clear winner in the marketplace. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --nrV5pXGjFVoU6l38rvvPQXBnjlh5DuKQC-- --wdCtl1hcxeP3rAoVV0jw7e2XwFccehfge Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAliDzwoACgkQ8AA1q7Z/VrKLIQCbB2mv6jqMzbflndc+d1bHCe3v z8MAn1Eop1Dg5RLNsLXZJIQA/75VAUOk =9vuK -----END PGP SIGNATURE----- --wdCtl1hcxeP3rAoVV0jw7e2XwFccehfge-- From nobody Sat Jan 21 16:49:25 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2974A12954A for ; Sat, 21 Jan 2017 16:49:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.5 X-Spam-Level: X-Spam-Status: No, score=-7.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se 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 1H5t7nSXphXm for ; Sat, 21 Jan 2017 16:49:22 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76D171293F0 for ; Sat, 21 Jan 2017 16:49:22 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 31F5DA3; Sun, 22 Jan 2017 01:49:19 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1485046159; bh=IeWmss80unpO6DoJuDCAaxp+yncjuXmckYdWTOJVt6Q=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=TfgaNQgd3AVt4Dz3XYRF0wQBo41cus8sUK5f2deqCLP1nduuvr4oG8nKlCJAWQDA7 upyMo3wV91j6I/wzgeqjcEJM+yfkyCqbQ5ZzkpmECdsmTp+kFvVNPIqgd286t9VwqV uSMieduldLvMgi9cAlU23VkOAl8IIuYV1iChybug= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 2D076A2; Sun, 22 Jan 2017 01:49:19 +0100 (CET) Date: Sun, 22 Jan 2017 01:49:19 +0100 (CET) From: Mikael Abrahamsson To: james woodyatt In-Reply-To: Message-ID: References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <99204933-5CB6-4E89-BD6A-FD40136DF6F5@steffann.nl> 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-1043836396-1485046159=:31101" Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2017 00:49:24 -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-1043836396-1485046159=:31101 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT On Fri, 20 Jan 2017, james woodyatt wrote: > It escaped my attention until now. I’m at a loss to understand how that > happened. I’m sure there must have been a contentious debate in 6MAN > that I completely missed. No. I brought it up in 6man after I discovered it and asked for procedural change, I don't know what the chairs decided to do after that. There was a question in 6man regarding this option, chairs interpreted the comments as no opposition, so 6man left it without comment (as far as I can tell). So it's easier (or at least was) to create new RA options in other working groups than it is to do it in 6man. -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-1043836396-1485046159=:31101-- From nobody Mon Jan 23 00:09:13 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E157A12949D for ; Mon, 23 Jan 2017 00:09:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.42 X-Spam-Level: X-Spam-Status: No, score=-7.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 6DlE6uP3qpTE for ; Mon, 23 Jan 2017 00:09:08 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3532812949A for ; Mon, 23 Jan 2017 00:09:07 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DFA39808; Mon, 23 Jan 2017 08:09:04 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 23 Jan 2017 08:09:01 +0000 Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Mon, 23 Jan 2017 16:08:54 +0800 From: "Liubing (Leo)" To: Victor Kuarsingh Thread-Topic: [v6ops] draft-ietf-v6ops-ula-usage-considerations Thread-Index: AdJsIL/eG1Un5ofxSVup0bRMt9w27wAFFI8AAAGv1gAAGgVqAAABfQaAAAAQPgACKUFiIA== Date: Mon, 23 Jan 2017 08:08:53 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45C2E99F11@nkgeml514-mbx.china.huawei.com> References: <67b3af77-3ab6-95f2-93c5-45d036efb935@bogus.com> <048a00cd-ff4f-abd8-cc15-36df70964748@gmail.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.191.175] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.5885BA21.01B4, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: b5e9a02f7d0c5cdadd0903115af64716 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-considerations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 08:09:12 -0000 SGkgVmljdG9yLA0KDQpTb3JyeSBmb3IgdGhlIGxhdGUgcmVzcG9uc2UuIFlvdXIgZm9sbG93aW5n IGNvbW1lbnRzIGFyZSB2ZXJ5IGNvbnN0cnVjdGl2ZSwgdGhhbmtzIGEgbG90Lg0KUGxlYXNlIHNl ZSByZXBsaWVzIGlubGluZS4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9t OiB2Nm9wcyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBWaWN0 b3IgS3VhcnNpbmdoDQo+IFNlbnQ6IEZyaWRheSwgSmFudWFyeSAxMywgMjAxNyAxMjowMiBBTQ0K PiBUbzogVGltIENob3duDQo+IENjOiB2Nm9wc0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3Y2 b3BzXSBkcmFmdC1pZXRmLXY2b3BzLXVsYS11c2FnZS1jb25zaWRlcmF0aW9ucw0KPiANCj4gU29y cnksIHB1bGxlZCB0cmlnZ2VyIHRvbyBmYXN0IG9uIGxhc3QgZW1haWwuDQo+IA0KPiAgQXMgYSB3 YXkgdG8gY29uZGVuc2UgdGhlIGRvY3VtZW50IGFuZCBhdHRlbXB0IHRvIGNvbnNvbGlkYXRlIHRo ZQ0KPiBpbmZvcm1hdGlvbi4gIFdvdWxkIGNvbmNlbnRyYXRpbmcgb24gdGhlIGZvbGxvd2luZyB0 aHJlZSBtb2RlbHMgIChsaXN0ZWQNCj4gYmVsb3cpIGJlIHdvcnRoIGNvbnNpZGVyaW5nPyAgV2Ug Y2FuIGFsc28ga2VlcCB3aGF0IGlzICBjdXJyZW50bHkgc2VjdGlvbg0KPiA1IChnZW5lcmFsIGNv bnNpZGVyYXRpb25zKSBhcyB3ZWxsLg0KPiANCj4gICgxKS4gSXNvbGF0ZWQgTmV0d29ya3MuDQo+ ICBCcmllZjogcG90ZW50aWFsIHZhbGlkIHVzZS4gIE5vdCBpbnRlbmRlZCBmb3IgKG9yIHNwZWNp ZmljYWxseSBkZW5pZWQpDQo+IEludGVybmV0IGNvbm5lY3Rpdml0eS4gIFdlIGhhdmUgYSBjb3Vw bGUgb2Ygc29saWQgdXNlIGNhc2VzIGhlcmUsIGxpc3QgIGtleQ0KPiBjb25zaWRlcmF0aW9ucyAN Cg0KW0JpbmddIEkgY2FuIGFkZCBhbm90aGVyIHNvbGlkIHVzZSBjYXNlLCB3aGljaCBpcyB0aGUg VUxBIGFkZHJlc3Npbmcgb2YgQUNQIGluIEFuaW1hIFdHJ3Mgd29yay4gKFNlZSBodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1hbmltYS1hdXRvbm9taWMtY29udHJvbC1wbGFu ZS0wNSNzZWN0aW9uLTUuOC4xICkgVGhpcyBpcyBub3Qgb25seSB1bmRlciBzdGFuZGFyZGl6YXRp b24sIGJ1dCBhbHNvIGFscmVhZHkgaW4gQ2lzY28ncyBjb21tZXJjaWFsIHByb2R1Y3RzLg0KDQpC dHcsIEkgZ3Vlc3Mgd2UgY291bGQgbWFrZSB0aGUgc3RhdGVtZW50IGEgYml0IG1vcmUgc3Ryb25n ZXIsIHRoYXQgd2UgcmVtb3ZlIHRoZSB3b3JkICJwb3RlbnRpYWwiPw0KDQooMikuIE11bHRpLWhv bWVkIC8gTXVsdGktYWRkcmVzc2VkIChpLmUuIFVMQStHVUEpLiBCcmllZjoNCj4gcG90ZW50aWFs IHZhbGlkIHVzZSwgb3RoZXIgd2F5cyB0byBzb2x2ZSBwcm9ibGVtDQoNCltCaW5nXSBBZ3JlZWQu IEkgdGhpbmsgdGhlIHdvcmQgInBvdGVudGlhbCIgaXMganVzdGlmaWVkIGhlcmUuDQoNCj4gKDMp IEludGVybmV0IGNvbm5lY3RlZC4gIE5vdCB2YWxpZCBjaG9pY2UsIGhhcm1mdWwsIGxpbWl0aW5n LCBhdm9pZC4NCg0KW0JpbmddIFRoZSBvcmlnaW5hbCBpbnRlbnRpb24gb2YgZG9jdW1lbnRpbmcg VUxBK05QVHY2L1Byb3h5IGlzIG5vdCB0byBwcm9tb3RlIHN1Y2ggdXNlIGNhc2VzLCByYXRoZXIs IHRvIGNvbnNpZGVyIGl0IGFzICJoZWxwbGVzcyIgY2hvaWNlIGluIHNvbWUgc2l0dWF0aW9uLiBC dXQgYWNjb3JkaW5nIHRvIHRoZSBXRydzIG9waW5pb24sIEkgdGhpbmsgdGhlIGp1c3RpZmljYXRp b24gb2YgVUxBK05QVHY2L1Byb3h5IG5lZWRzIHRvIGJlIG1vcmUgZXhwbGljaXQgYW5kIHN0cm9u Z2VyIGluIHRoaXMgZG9jdW1lbnQuDQoNCkJlc3QgcmVnYXJkcywNCkJpbmcNCg0KPiANCj4gcmVn YXJkcywNCj4gDQo+IFZpY3RvciBLDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4g Pg0KPiA+IE9uIFRodSwgSmFuIDEyLCAyMDE3IGF0IDEwOjE3IEFNLCBUaW0gQ2hvd24gPFRpbS5D aG93bkBqaXNjLmFjLnVrPg0KPiB3cm90ZToNCj4gPj4+IE9uIDEyIEphbiAyMDE3LCBhdCAwMjo1 MiwgQnJpYW4gRSBDYXJwZW50ZXINCj4gPGJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbT4gd3Jv dGU6DQo+ID4+Pg0KPiA+Pj4gT24gMTIvMDEvMjAxNyAxNTowMywgam9lbCBqYWVnZ2xpIHdyb3Rl Og0KPiA+Pj4+IEZvciBtZSBwZXJzb25hbGx5LCB0aGUgcHJlc2VuY2Ugb2YgbnB0NiBvciBpbmRl ZWQgYW55IGZvcm0gb2YgdWxhDQo+ID4+Pj4gb25seSBkZXBsb3ltZW50LCBzYXZlICBwZXJoYXBz IGZvciBlcGhlbWVyYWwgcHJpdmF0ZSBuZXR3b3JrcyBpcyBhDQo+ID4+Pj4gYnJpZ2h0IGxpbmUg bm90IHRvIGJlIGNyb3NzZWQuIEkgZmluZCBpdCBoYXJkIHRvIHN1cHBvcnQgYSBkb2N1bWVudA0K PiA+Pj4+IHRoYXQgdHJlYXRzIHRoZSBzdWJqZWN0IHdpdGhvdXQgcmVjb21tZW5kaW5nIG5ldmVy IHRvIGRvIHRob3NlDQo+IHRoaW5ncy4NCj4gPj4+DQo+ID4+PiBJIGFncmVlIHdpdGggdGhhdCBh bmQgd2l0aCBWaWN0b3IncyBjb21tZW50LiBCdXQgZG8geW91IHRoaW5rIHdlDQo+ID4+PiBjb3Vs ZCBlbGV2YXRlIHRoaXMgdG8gQkNQPyBJJ20gbm90IGNvbWZvcnRhYmxlIHRoYXQgd2UgaGF2ZSBl bm91Z2gNCj4gPj4+IGV4cGVyaWVuY2UgdG8gZG8gdGhhdC4NCj4gPj4NCj4gPj4gSSBhZ3JlZSB3 aXRoIEpvZWwsIEJyaWFuLCBMb3JlbnpvIGFuZCBWaWN0b3LigJlzIGNvbW1lbnRzLg0KPiA+Pg0K PiA+PiBJIHRoaW5rIHdvcmsgc2hvdWxkIGNvbnRpbnVlIG9uIHRoZSBkb2N1bWVudCwgYnV0IGFz IEJyaWFuIHN1Z2dlc3RzIEJDUA0KPiBpcyBsaWtlbHkgcHJlbWF0dXJlOyBJbmZvcm1hdGlvbmFs IGlzIG1vcmUgYXBwcm9wcmlhdGUsIGlmIHdlIGNhbiBjb25kZW5zZQ0KPiB0aGUgdGV4dCB0b3dh cmRzIGNvbnNlbnN1cy4NCj4gPj4NCj4gPj4gVGhlIGNoYWxsZW5nZSBpcyBmaW5kaW5nIHRoZSBt aW5pbXVtIHNldCBvZiBtZXNzYWdlcyB0byBpbmNsdWRlIGluIHRoZQ0KPiBkb2N1bWVudCB0byBh Y2hpZXZlIHRoYXQgY29uc2Vuc3VzIHRvIHB1Ymxpc2guICBGb3IgZXhhbXBsZSwgSeKAmW0gbm90 DQo+IGNvbWZvcnRhYmxlIHdpdGggU2VjdGlvbiA0LjIuMSBvbiBOUFR2Ni4gQnV0IGRpZmZlcmVu dGlhdGluZyBVTEEtb25seSBmcm9tDQo+IFVMQStHVUEgaXMgaW1wb3J0YW50LCBhcyBpcyBlbXBo YXNpc2luZyB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIElQdjYgVUxBDQo+IGFuZCBJUHY0IFJGQzE5 MTggYXNzdW1wdGlvbnMuDQo+ID4+DQo+ID4+IFRpbQ0KPiA+Pg0KPiA+Pj4+DQo+ID4+Pj4gam9l bA0KPiA+Pj4+DQo+ID4+Pj4gT24gMS8xMS8xNyA3OjM5IEFNLCBSb24gQm9uaWNhIHdyb3RlOg0K PiA+Pj4+PiBGb2xrcywNCj4gPj4+Pj4NCj4gPj4+Pj4gRCByYWZ0LWlldGYtdjZvcHMtdWxhLXVz YWdlLWNvbnNpZGVyYXRpb25zIHdhcyBpbnRyb2R1Y2VkIDMuNSB5ZWFycw0KPiBhZ28sIGJ1dCBo YXMgbWFkZSBsaXR0bGUgcHJvZ3Jlc3MgaW4gdGhlIGxhc3QgeWVhci4gVGhlcmVmb3JlLCBpdCBi ZWNvbWUNCj4gbmVjZXNzYXJ5IGZvciB0aGUgY2hhaXJzIHRvIHJlZXZhbHVhdGUgd2hldGhlciB0 aGlzIGRyYWZ0IHNob3VsZCBjb250aW51ZSB0bw0KPiBiZSBhIFdHIGl0ZW0uDQo+ID4+Pj4+DQo+ ID4+Pj4+IElmIHlvdSBoYXZlIGFuIG9waW5pb24gb24gdGhpcyBzdWJqZWN0LCBwbGVhc2UgcG9z dCBpdCB0byB0aGUgbWFpbGluZyBsaXN0DQo+IGJ5IDEvMjUvMTcuIE9wdGlvbnMgYXJlOg0KPiA+ Pj4+Pg0KPiA+Pj4+PiAxKSBDb250aW51ZSB0byB3b3JrIG9uIHRoZSBkcmFmdCB3aXRoIGFuIGV5 ZSB0b3dhcmQgcHVibGljYXRpb24gaW4NCj4gPj4+Pj4gMjAxNw0KPiA+Pj4+PiAyKSBBbGxvdyB0 aGUgZHJhZnQgdG8gZXhwaXJlDQo+ID4+Pj4+DQo+ID4+Pj4+IFNpbGVuY2Ugb3IgbGltaXRlZCBy ZXNwb25zZSB3aWxsIGJlIGludGVycHJldGVkIGFzIGEgbGFjayBvZiBpbnRlcmVzdCBpbg0KPiB0 aGUgZHJhZnQuDQo+ID4+Pj4+DQo+ID4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBSb24sIExlZSBhbmQNCj4gRnJlZA0KPiA+Pj4+Pg0KPiA+Pj4+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4+PiB2Nm9w cyBtYWlsaW5nIGxpc3QNCj4gPj4+Pj4gdjZvcHNAaWV0Zi5vcmcNCj4gPj4+Pj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KPiA+Pj4+Pg0KPiA+Pj4+DQo+ID4+ Pj4NCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gPj4+PiB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4gPj4+PiB2Nm9w c0BpZXRmLm9yZw0KPiA+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v djZvcHMNCj4gPj4+Pg0KPiA+Pj4NCj4gPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+ID4+PiB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4gPj4+IHY2b3Bz QGlldGYub3JnDQo+ID4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2 b3BzDQo+ID4+Pg0KPiA+Pg0KPiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiA+PiB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4gPj4gdjZvcHNAaWV0Zi5v cmcNCj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KPiAN Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gdjZv cHMgbWFpbGluZyBsaXN0DQo+IHY2b3BzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vdjZvcHMNCg== From nobody Mon Jan 23 00:41:51 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F729129543 for ; Mon, 23 Jan 2017 00:41:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 ya55XyoO42FS for ; Mon, 23 Jan 2017 00:41:48 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BD041294A1 for ; Mon, 23 Jan 2017 00:41:48 -0800 (PST) Received: from [192.168.3.102] (142-135-17-190.fibertel.com.ar [190.17.135.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id B679E836A2; Mon, 23 Jan 2017 09:41:44 +0100 (CET) To: Mikael Abrahamsson , james woodyatt References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <99204933-5CB6-4E89-BD6A-FD40136DF6F5@steffann.nl> From: Fernando Gont Message-ID: <0cf61742-13c5-5e55-e286-4bcd2091e776@si6networks.com> Date: Mon, 23 Jan 2017 04:56:14 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 08:41:49 -0000 On 01/21/2017 09:49 PM, Mikael Abrahamsson wrote: > > There was a question in 6man regarding this option, chairs interpreted > the comments as no opposition, so 6man left it without comment (as far > as I can tell). > > So it's easier (or at least was) to create new RA options in other > working groups than it is to do it in 6man. Isn't 6man where that's supposed to happen? :-) Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Jan 23 11:30:53 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19D601297CC for ; Mon, 23 Jan 2017 11:30:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 u5ysro1bhQLD for ; Mon, 23 Jan 2017 11:30:49 -0800 (PST) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A4431297C9 for ; Mon, 23 Jan 2017 11:30:49 -0800 (PST) Received: by mail-pf0-x22d.google.com with SMTP id f144so43385423pfa.2 for ; Mon, 23 Jan 2017 11:30:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=PNoKuj1/zRRntJPZZJWhjfuZyMBNEJWL9tNVedjDiek=; b=N4IgLgaBeONubC9fKi8wzfiQvp2Isnbl5X0Go8/5Z4wKmmFcE60aRf8iTH1q/kb9cY kjLXW8eDQlVWQ4xzsQwjO3Ha8DIvJ9ZmCtCqoOc6HfLdk6/WeA/XRXFC1LjwKyyoMKlh uijLVr1Fn7Es/NGG7991c7YT2BhXN3hkAKAKP+MX3b3BV2MMHBlcyWm/n5KshwZNpu8x 0gyRg9EZLeGqnBuVmo74cdUWo+F7ESB6Lj4zd900TDApneuu4z5iwWwY8GGYhNh7WLY0 A9TzK89hPPpM3/DFRxsJ/kfI3kNSOjnlwansEsD4yxmkwQVhI4/9qc1k4PGsQq++bbo/ yL9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=PNoKuj1/zRRntJPZZJWhjfuZyMBNEJWL9tNVedjDiek=; b=QA337CRwX+D/RbJbZrL9SnciBWumiPPKd/ylP24ZcDnlLYjWJOQU3HalfuTeukPqIb uyLKr0JHRggrB27OMd3od7u9L3DQn0jkeMexBOLMV7JMcWisYY2ejch7YvWtBQFLjzm+ 0bVYDFGa7ZBeThlZZbOKLIPDKaama6bcoeSKR3se78jNsiINfpwmqbx5QeVpKhFksv6Y KrM8yBfcaGSZW9dpmbyR6m7/aZNJoKNSPYxOBiHoOvsNTTrPgTUrCqBiqIpqWZ9N2Luw TN3wDKQG2QGmgWupLLhbkm46Oy0alroji4b3MMa67VSfOIXec3lynp4SOSBmIsxMKa/3 25VQ== X-Gm-Message-State: AIkVDXLhXMRg0laYa+iD8Eshus2yDqThLm6jt8YqLT7qAJbtoaudZcUKQTJ67OyNjxwSkw== X-Received: by 10.84.216.70 with SMTP id f6mr45681534plj.10.1485199848474; Mon, 23 Jan 2017 11:30:48 -0800 (PST) Received: from ?IPv6:2406:e007:6c0c:1:28cc:dc4c:9703:6781? ([2406:e007:6c0c:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id q22sm38752372pfj.77.2017.01.23.11.30.46 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Jan 2017 11:30:47 -0800 (PST) To: v6ops@ietf.org References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <99204933-5CB6-4E89-BD6A-FD40136DF6F5@steffann.nl> <0cf61742-13c5-5e55-e286-4bcd2091e776@si6networks.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <07cad5c4-1744-7474-6c5e-c0bde9a225c2@gmail.com> Date: Tue, 24 Jan 2017 08:30:48 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <0cf61742-13c5-5e55-e286-4bcd2091e776@si6networks.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 19:30:51 -0000 On 23/01/2017 20:56, Fernando Gont wrote: > On 01/21/2017 09:49 PM, Mikael Abrahamsson wrote: >> >> There was a question in 6man regarding this option, chairs interpreted >> the comments as no opposition, so 6man left it without comment (as far >> as I can tell). >> >> So it's easier (or at least was) to create new RA options in other >> working groups than it is to do it in 6man. > > Isn't 6man where that's supposed to happen? :-) Seriously, no. That isn't written down anywhere. RFC4861 refers to RFC4443 which just requires IETF RFC publication. It's not really possible to specify a particular WG in the IANA Considerations, because WGs may be closed. Brian From nobody Mon Jan 23 14:38:32 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 815AD1293D9 for ; Mon, 23 Jan 2017 14:38:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 Z-khX2NK0fgV for ; Mon, 23 Jan 2017 14:38:28 -0800 (PST) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93373128E19 for ; Mon, 23 Jan 2017 14:38:28 -0800 (PST) Received: by mail-pg0-x234.google.com with SMTP id t6so48478744pgt.3 for ; Mon, 23 Jan 2017 14:38:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:message-id:mime-version:subject:date:references:to:in-reply-to; bh=3RGqeQ74KHWumeF2kByJzFGPtJ/jn4ISUgpOD+iDO2w=; b=hUKSTvoK/DPsLuXHdDtFQaSGEoFOn5YidpcceFjP8QRZK0ojTEgpgqAk6wQn1pE4wu n/G7oMKndvNpLLim8EBbehYG+pK1Y/qTSNCs3+MgwB9nX00DjxdrI++byecAcGeL/WMb Q+JOcqrlbUV/GzL5/KTEx5I/Z08cqSbxkMVO6L8o44oI15cYX8lgsCYXuLVIh7rvGBN9 /XRIB7ic6mTwyeVTBYCSBhzIHHj2uEJdMMVr7iLZo/iCiIwMV2trse1GY5FyRlN6XjI/ EIrhK9UrnozIhWKso+gx9fvwbhrZzvR6KR2pPdNRRsNCntfggf0OnWDBtFhluhT4GGr6 4T+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :references:to:in-reply-to; bh=3RGqeQ74KHWumeF2kByJzFGPtJ/jn4ISUgpOD+iDO2w=; b=aUirFIfgZkjr2PKEveZrxSVLv+kpK4rozRqjwa2XRk7mgzryP6yhefICX7QxWtopRc vyVkGy1st3Xcj2w/mj6GgbTdTd3cb/HXT3LggkSJypXFYmiX+D5Iy9Gp2CQ5Xo5Dy2NF sUgL7h9WXnxBOLm9va7lM4W9lPgf16ix2ORzpruIjelsHlZeS0krzVS2g5PZhdoe1WuQ VWgL5tW/061F3cRnCx6VHNKHYdaXjWbwrKL70dM2HCIsYA3U+cXziY5Hp0O3zPfEU1SB SgNt/Xt7lsqcWHfM+DU4tDWph121toMvSxGslweo+H96+jirPzF6q8jFrGwzsl2pjOXH 15Xw== X-Gm-Message-State: AIkVDXJx1TlaQKN9+4uVMznSp/ce4nOLKFWwlFhGRTKmFJDdCB/i7o3YLOb6bxA6/QImREM7 X-Received: by 10.84.171.195 with SMTP id l61mr46146138plb.84.1485211107683; Mon, 23 Jan 2017 14:38:27 -0800 (PST) Received: from ?IPv6:2001:5a8:4:2290:fd78:14ee:aad:8493? ([2001:5a8:4:2290:fd78:14ee:aad:8493]) by smtp.gmail.com with ESMTPSA id e90sm39296578pfl.32.2017.01.23.14.38.26 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 23 Jan 2017 14:38:27 -0800 (PST) From: james woodyatt Content-Type: multipart/alternative; boundary="Apple-Mail=_8A0CF995-244B-4796-B51C-75CCD6FF5C24" Message-Id: <672582C8-BE04-4CF1-B26E-E8CF3235F6DB@google.com> Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Date: Mon, 23 Jan 2017 14:38:25 -0800 References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <99204933-5CB6-4E89-BD6A-FD40136DF6F5@steffann.nl> <64592AC1-EFE9-4AA9-8C94-CF48986EC485@google.com> <892E650B-5F77-4FB9-B157-B84300E15CF6@fugue.com> To: IPv6 Ops WG In-Reply-To: X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [v6ops] sidetrack on DNS-SD vs. DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 22:38:30 -0000 --Apple-Mail=_8A0CF995-244B-4796-B51C-75CCD6FF5C24 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jan 21, 2017, at 07:57, Ted Lemon wrote: > On Jan 21, 2017, at 6:56 AM, Philip Homburg = wrote: >> I assume you can just do a mDNS lookup for _dns._udp.local. >=20 > Only if there is a server listening for such lookups on the local = wire. This is, in fact, what I first proposed to do in the dark days before we = had RDNSS in the event hosts found themselves on IPv6-only links where = DHCPv6 was not available. That, and a well-known anycast address for use = in the event that mDNS-SD fails. That proposal was not well received, as = I recall. People were=E2=80=94 rightly, I think=E2=80=94 concerned that = discovering the uDNS resolving server by mDNS-SD could entail saddening = security considerations, and standardizing a single well-known anycast = address for uDNS servers seemed perverse (before 2001:4860:4860::8888 = showed up as a de facto convention), so that=E2=80=99s why I believe the = old expired RDNSS draft was pulled out of mothballs. Meanwhile, the = appearance of mDNS filters in layer-2 switching fabric convinced me that = we were going to need help from the network infrastructure getting uDNS = bootstrapped. So that=E2=80=99s why I=E2=80=99m here, and I=E2=80=99m not still = banging on using mDNS to bootstrap uDNS. >> The one thing you can't get is the search domain. Though of course >> that could be encoded as a TXT record in the relevant DNS resolver = pointed >> to by _dns._udp.local. See RFC 6763, section 11, Discovery of Browsing and Registration Domains = (Domain Enumeration). >> The one thing that is possible in DHCP and almost impossible in any = of the >> alternatives (RA, DNS-SD) is configuration that varies per host. Some = of >> the classical DHCP options, like hostname, root path, boot file >> name, are host specific. >=20 > ND has host-specific configuration. But boot service is actually = precisely what DHCP is best at. I=E2=80=99ve been arguing for a long time that the perception of the = need for this is misplaced. We need to build to an architecture where = host configurations need not be individually customized dynamically by a = central network service *DURING* the network attachment process. It = should suffice to configure a host sufficiently to acquire general = access to the network, then *AFTER* it is attached and its interface = addresses assigned, for its hosted applications to acquire = individualized configurations from the network to access local and = global services properly. >> It seems that the one thing that was left out of DNS-SD is support = for >> host specific configuration. I guess it should be easy enough to put = in. >=20 > I suspect that it would be impossible without extensions, since the = server doesn't have a client identifier to check. I suppose the client = could send an EDNS0 option with an identifier, but it seems silly to go = to the trouble when DHCP already solves this problem. This is, indeed, what it seems to me that everyone who wants to keep = stateful DHCP around says is the principle reason they need it. I see no reason to give them for this another thing entirely while they = actively protest that they don=E2=80=99t want another thing at all. Let = them keep stateful DHCP for meeting their need to be fastidious. I agree = they need something for this, and DHCP is the thing they already have. = The rest of us can proceed with building to an architecture where hosts = do not actually require individual service layer configurations to be = applied before the network layer host attachment process can even be = completed, and thus do not need DHCP clients at all, even to = interoperate in the most authoritarian of service access environments. = Those people will eventually come along and see the way forward. No need = to hurry them. --james woodyatt > --Apple-Mail=_8A0CF995-244B-4796-B51C-75CCD6FF5C24 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Jan 21, 2017, at 07:57, Ted Lemon <mellon@fugue.com> = wrote:
    On Jan 21, 2017, at 6:56 AM, Philip Homburg <pch-v6ops-6@u-1.phicoh.com> wrote:
    I assume you can just do = a mDNS lookup for _dns._udp.local.

    Only if there is a server listening for such lookups on the = local wire.

    This is, in fact, what I first proposed to do in = the dark days before we had RDNSS in the event hosts found themselves on = IPv6-only links where DHCPv6 was not available. That, and a well-known = anycast address for use in the event that mDNS-SD fails. That proposal = was not well received, as I recall.

    People were=E2=80=94 rightly, I think=E2=80=94 = concerned that discovering the uDNS resolving server by mDNS-SD could = entail saddening security considerations, and standardizing a single = well-known anycast address for uDNS servers seemed perverse (before = 2001:4860:4860::8888 showed up as a de facto convention), so that=E2=80=99= s why I believe the old expired RDNSS draft was pulled out of mothballs. = Meanwhile, the appearance of mDNS filters in layer-2 switching fabric = convinced me that we were going to need help from the network = infrastructure getting uDNS bootstrapped.

    So that=E2=80=99s why I=E2=80=99m here, and I=E2=80=99= m not still banging on using mDNS to bootstrap uDNS.

    The one thing you can't = get is the search domain. Though of course
    that could be encoded as a TXT record in the = relevant DNS resolver pointed
    to by = _dns._udp.local.

    See RFC 6763, section 11, Discovery of Browsing and Registration Domains (Domain = Enumeration).

    The one thing that is possible in DHCP and almost impossible = in any of the
    alternatives (RA, DNS-SD) is configuration = that varies per host. Some of
    the classical DHCP options, = like hostname, root path, boot file
    name, are host = specific.

    ND has host-specific = configuration.   But boot service is actually precisely what = DHCP is best at.

    I=E2=80=99ve been arguing for a long time that the = perception of the need for this is misplaced. We need to build to an = architecture where host configurations need not be individually = customized dynamically by a central network service *DURING* the network = attachment process. It should suffice to configure a host sufficiently = to acquire general access to the network, then *AFTER* it is attached = and its interface addresses assigned, for its hosted applications to = acquire individualized configurations from the network to access local = and global services properly.

    It seems that the one thing that was left out = of DNS-SD is support for
    host specific configuration. I = guess it should be easy enough to put in.

    I suspect that it would be impossible without extensions, = since the server doesn't have a client identifier to check. =   I suppose the client could send an EDNS0 option with an = identifier, but it seems silly to go to the trouble when DHCP already = solves this problem.

    This is, indeed, what it seems to me that = everyone who wants to keep stateful DHCP around says is the principle = reason they need it.

    I see no reason = to give them for this another thing entirely while they actively protest = that they don=E2=80=99t want another thing at all. Let them keep = stateful DHCP for meeting their need to be fastidious. I agree they need = something for this, and DHCP is the thing they already have. The rest of = us can proceed with building to an architecture where hosts do not = actually require individual service layer configurations to be applied = before the network layer host attachment process can even be completed, = and thus do not need DHCP clients at all, even to interoperate in the = most authoritarian of service access environments. Those people will = eventually come along and see the way forward. No need to hurry = them.


    --james woodyatt <jhw@google.com>



    = --Apple-Mail=_8A0CF995-244B-4796-B51C-75CCD6FF5C24-- From nobody Mon Jan 23 15:06:59 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FA8D1293F5 for ; Mon, 23 Jan 2017 15:06:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 qSJJOMRh_odv for ; Mon, 23 Jan 2017 15:06:57 -0800 (PST) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C69051293E8 for ; Mon, 23 Jan 2017 15:06:56 -0800 (PST) Received: by mail-qt0-x22b.google.com with SMTP id k15so151838585qtg.3 for ; Mon, 23 Jan 2017 15:06:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=bLXDIhUoxqxMoyJ1hu80dPWkznYbzvTomhEI/Rh2rPQ=; b=Gi54bISk3ttKCvBM0aYWYnr0tT6buKax3oc+tyt5xSyEF5gfTEDxnkgv0wCKBu6icQ ta83JcuZUeHTc/qtaXWC2v3x2UrG3zG1FAp/rOJeCuz0mk5oSRhYYD/Eg9uE9XLHr+1B AD8VxgiAnwQG1ogNUvxtWMXCgUWzcYAYmWqwFfrwMomppZyxYEPjfadhGPU9cw/TDFMO 1kzxkVHWaBg1LD4H3jJN5cYtXpyy5fr7zYsvxiwZFN+kdqVFSiBH/Y244x67xNnYQfyy OqYQ5M5fAbUHjZnZxs1plqE1vka5J1W0T/kX8EqjO2qTORMR+B5EK1tqPtmnmOcJmQzO d68Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=bLXDIhUoxqxMoyJ1hu80dPWkznYbzvTomhEI/Rh2rPQ=; b=bfdqJ5CLuE9gvhAgtfcDXb2blZx06KgeuwsTPi94/EQRhtjRS7kUvrzU1makMfaB+l BiJxGq2pntV6IhBmS1bJ+BmkQIUPGJ1k5kFEgORLJwYpUAzmI2ppxIK5X7E82925XqC5 KyrK+mAfPcZ+jEAbQmuOWDJJ7pbWXwOAWDZAeJpXQqmSyAvSc+MvN0tdwSA2dcTHrA8x IX0wPCcIwwGE65FKn4cYgH/CX9OH70CtsjhnwqlvScXzk02cDaP4JbG/vhVliY1UbND6 s4gz/xcfQcH3rvMVwq3cs5CnVc73uveWAYbyjuy7UcuBV4Z2SmuPH/Py98tyQGNM6kAN 8JgA== X-Gm-Message-State: AIkVDXJjsjwU9f5NijfBKE12wvTVkdfgryWr029ZsFfdvIWJ9CLPCeEZSHr5DsW7z3sX4g== X-Received: by 10.237.34.38 with SMTP id n35mr24928908qtc.253.1485212815946; Mon, 23 Jan 2017 15:06:55 -0800 (PST) Received: from [192.168.1.228] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id s2sm14426938qts.25.2017.01.23.15.06.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Jan 2017 15:06:54 -0800 (PST) From: Ted Lemon Message-Id: <0C144187-58F2-42B1-AE6C-10CA7608A778@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_DBF2A386-6EA9-400B-8F56-A4507B1A63EE" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Mon, 23 Jan 2017 18:06:52 -0500 In-Reply-To: <672582C8-BE04-4CF1-B26E-E8CF3235F6DB@google.com> To: james woodyatt References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <99204933-5CB6-4E89-BD6A-FD40136DF6F5@steffann.nl> <64592AC1-EFE9-4AA9-8C94-CF48986EC485@google.com> <892E650B-5F77-4FB9-B157-B84300E15CF6@fugue.com> <672582C8-BE04-4CF1-B26E-E8CF3235F6DB@google.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] sidetrack on DNS-SD vs. DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 23:06:58 -0000 --Apple-Mail=_DBF2A386-6EA9-400B-8F56-A4507B1A63EE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jan 23, 2017, at 5:38 PM, james woodyatt wrote: > I see no reason to give them for this another thing entirely while = they actively protest that they don=E2=80=99t want another thing at all. = Let them keep stateful DHCP for meeting their need to be fastidious. I = agree they need something for this, and DHCP is the thing they already = have. The rest of us can proceed with building to an architecture where = hosts do not actually require individual service layer configurations to = be applied before the network layer host attachment process can even be = completed, and thus do not need DHCP clients at all, even to = interoperate in the most authoritarian of service access environments. = Those people will eventually come along and see the way forward. No need = to hurry them. Yup. --Apple-Mail=_DBF2A386-6EA9-400B-8F56-A4507B1A63EE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Jan 23, 2017, at 5:38 PM, james woodyatt <jhw@google.com> = wrote:
    I see no reason to give them for this another = thing entirely while they actively protest that they don=E2=80=99t want = another thing at all. Let them keep stateful DHCP for meeting their need = to be fastidious. I agree they need something for this, and DHCP is the = thing they already have. The rest of us can proceed with building to an = architecture where hosts do not actually require individual service = layer configurations to be applied before the network layer host = attachment process can even be completed, and thus do not need DHCP = clients at all, even to interoperate in the most authoritarian of = service access environments. Those people will eventually come along and = see the way forward. No need to hurry = them.

    Yup.

    = --Apple-Mail=_DBF2A386-6EA9-400B-8F56-A4507B1A63EE-- From nobody Tue Jan 24 01:23:26 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D9281294C8 for ; Tue, 24 Jan 2017 01:23:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.098 X-Spam-Level: X-Spam-Status: No, score=-10.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=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 rsOPea5b3UpH for ; Tue, 24 Jan 2017 01:23:23 -0800 (PST) Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C42921294B7 for ; Tue, 24 Jan 2017 01:23:23 -0800 (PST) Received: from nene.ripe.net ([193.0.23.10]) by mahimahi.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cVxJx-000BfF-2O; Tue, 24 Jan 2017 10:23:22 +0100 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:5009::1d9]) by nene.ripe.net with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84_2) (envelope-from ) id 1cVxJw-0002aM-Sb; Tue, 24 Jan 2017 10:23:20 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_4BC841A2-1905-487A-8BC1-BBAB61DCE73C" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Nathalie Trenaman In-Reply-To: <022959E8-224B-447D-A844-17C20FA5A42E@steffann.nl> Date: Tue, 24 Jan 2017 10:23:20 +0100 Message-Id: <02E4EC70-348C-4EA4-94F0-5C9608C6D35E@ripe.net> References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <99204933-5CB6-4E89-BD6A-FD40136DF6F5@steffann.nl> <64592AC1-EFE9-4AA9-8C94-CF48986EC485@google.com> <892E650B-5F77-4FB9-B157-B84300E15CF6@fugue.com> <022959E8-224B-447D-A844-17C20FA5A42E@steffann.nl> To: Sander Steffann X-Mailer: Apple Mail (2.3124) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: ------------ X-RIPE-Spam-Report: Spam Total Points: -12.6 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP -3.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.0 HTML_MESSAGE BODY: HTML included in message X-RIPE-Signature: b23882c8c47abee4cf35af21618ca92a9765f469581240a0d47176ab8ff71a1d Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2017 09:23:24 -0000 --Apple-Mail=_4BC841A2-1905-487A-8BC1-BBAB61DCE73C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, >=20 > I'm getting confused... There seem to be too many different = configuration mechanisms to keep a coherent model in my mind. What is = supposed to go where? We have RA for layer-3 options and DNS, for a bare = minimum network configuration. Then we have DHCPv6 both stateless = (layer-4+ IPv6, and some layer-3 IPv4 stuff like DS-Lite and MAP) = stateful (with additional layer-3 IPv6 options). And then we have DNS-SD = with even more options. >=20 > All of these also have different push and pull models. >=20 > I give a lot of IPv6 training, and I'm struggling with how to explain = to my IPv6-newbie students how this all fits together... It all comes = back to the problem for most network admins that IPv6 provides a lot of = cool features, but the number of possible combinations is so large that = they don't know what to do anymore. The learning curve for understanding = all the options and protocols and possible combination is getting so = steep that it's becoming a barrier to less experienced network admins... >=20 > I hope someone can give me a clear picture of what the intended = architecture behind all these protocols is. >=20 > Cheers, > Sander +1 from another puzzled/concerned IPv6 trainer. I=E2=80=99m trying to = keep track, but it keeps getting more complex, to a point where I see = people new to IPv6 tune out and give up.=20 Cheers, Nathalie Trenaman --Apple-Mail=_4BC841A2-1905-487A-8BC1-BBAB61DCE73C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,


    I'm getting = confused... There seem to be too many different configuration mechanisms = to keep a coherent model in my mind. What is supposed to go where? We = have RA for layer-3 options and DNS, for a bare minimum network = configuration. Then we have DHCPv6 both stateless (layer-4+ IPv6, and = some layer-3 IPv4 stuff like DS-Lite and MAP) stateful (with additional = layer-3 IPv6 options). And then we have DNS-SD with even more = options.

    All of these also have different = push and pull models.

    I give a lot of IPv6 = training, and I'm struggling with how to explain to my IPv6-newbie = students how this all fits together... It all comes back to the problem = for most network admins that IPv6 provides a lot of cool features, but = the number of possible combinations is so large that they don't know = what to do anymore. The learning curve for understanding all the options = and protocols and possible combination is getting so steep that it's = becoming a barrier to less experienced network admins...
    I hope someone can give me a clear picture of what the = intended architecture behind all these protocols is.

    Cheers,
    Sander


    +1 from another = puzzled/concerned IPv6 trainer. I=E2=80=99m trying to keep track, but it = keeps getting more complex, to a point where I see people new to IPv6 = tune out and give up. 

    Cheers,
    Nathalie = Trenaman

    = --Apple-Mail=_4BC841A2-1905-487A-8BC1-BBAB61DCE73C-- From nobody Tue Jan 24 02:20:49 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE99D129587 for ; Tue, 24 Jan 2017 02:20:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=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 4GC1y_EJu-xn for ; Tue, 24 Jan 2017 02:20:45 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD591295A4 for ; Tue, 24 Jan 2017 02:20:44 -0800 (PST) Received: from stereo.hq.phicoh.net ([::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #127) id m1cVyDS-0000E1C; Tue, 24 Jan 2017 11:20:42 +0100 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bF054DD66@u-1.phicoh.com References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <99204933-5CB6-4E89-BD6A-FD40136DF6F5@steffann.nl> <64592AC1-EFE9-4AA9-8C94-CF48986EC485@google.com> <892E650B-5F77-4FB9-B157-B84300E15CF6@fugue.com> <672582C8-BE04-4CF1-B26E-E8CF3235F6DB@google.com> In-reply-to: Your message of "Mon, 23 Jan 2017 14:38:25 -0800 ." <672582C8-BE04-4CF1-B26E-E8CF3235F6DB@google.com> Date: Tue, 24 Jan 2017 11:20:40 +0100 Archived-At: Cc: james woodyatt Subject: Re: [v6ops] sidetrack on DNS-SD vs. DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2017 10:20:48 -0000 > I see no reason to give them for this another thing entirely while > they actively protest that they dont want another thing at all. > Let them keep stateful DHCP for meeting their need to be fastidious. > I agree they need something for this, and DHCP is the thing they > already have. The rest of us can proceed with building to an > architecture where hosts do not actually require individual service > layer configurations to be applied before the network layer host > attachment process can even be completed, and thus do not need DHCP > clients at all, even to interoperate in the most authoritarian of > service access environments. Those people will eventually come > along and see the way forward. No need to hurry them. Looking at IPv6 as IPv4 with longer addresses and not as let's change random things and hope that it will make IPv6 better... I never felt the need for DNS-SD. I can understand the motivation but in practice DHCPv4 just works. It is very easy to debug. There is one protocol to watch, one exchange. If something is wrong it shows up in the DHCP exchange. I certainly appreciate DNS-SD from a protocol point of view. Way nicer and more general than DHCP. So if DNS-SD were a proper super set of stateless DHCPv6 than it would be obvious to move to a future where RAs and DHCPv6 provide address assignment and DNS-SD would provide configuration. However the way you describe it, you need DHCPv6 at least for host specific configuration unless all hosts implement a new configuration protocol. Which would bring the total number to 4 (RA, DHCPv6, DNS-SD, and an undisclosed per host configuration protocol). In that world, it makes way more sense, both for host operating systems and network operators to completely ignore DNS-SD and stick to RA and DHCPv6. (And publish an RFC that makes implementing both RA and DHCPv6, including IA_NA mandatory) From nobody Tue Jan 24 14:50:47 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D2E81294C6 for ; Tue, 24 Jan 2017 14:50:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 KOdzmuC1QaJd for ; Tue, 24 Jan 2017 14:50:45 -0800 (PST) Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 378971294BB for ; Tue, 24 Jan 2017 14:50:45 -0800 (PST) Received: by mail-pg0-x22c.google.com with SMTP id 204so58520005pge.0 for ; Tue, 24 Jan 2017 14:50:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:message-id:mime-version:subject:date:references:to:in-reply-to; bh=J6nQGBMB+fS3DUyyGWqHYb/SstiD8nsWDdM8vthnvWI=; b=g5f3E2cCwh662G+RFj9hzcMo28Vvn9GcXmbnIQIuXflpDpqSqgeyMZJNynayOaROPd 3CznvvaCdZPA2VExH0OqA0jS+37tlbWmquRKwLGQ/6nOtovMg11GEPiwXe9p/aFAjBFb toH/Hfe7QKU8qWAn6zA1YKJIr4NeSlmXgcxLAI+aFzWJ9cz2HLSQrLrTtfpVbu4Sblp5 NgTan1ZavkoLSGLRBr/MPf+Y29USHriWgbDK6HRkOnXXghzHLbPKy+9tPXo4VXwPTio0 PeFnqm5gAMK3Qfv0tJ45AJmS3fYnu4wJvz9ipNcgECmcD04YzD+mgmoyXQIi7euZYYm+ 3cBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :references:to:in-reply-to; bh=J6nQGBMB+fS3DUyyGWqHYb/SstiD8nsWDdM8vthnvWI=; b=Y5EEMbFh2B/M4NOsV9zOYZxH2AmBZYX4zl2hbSGylIvs8nsd0oYQm4AaYAj76oN2HF wsXtqs0mXHbnxsAkeJ00YUsMbdz/cKO1oq3WUpLlnp1nPkDXwr2jM3GX2ciO3HetiPHA Lg2Ms0CL06FekaPVnxQlUopstevCP/XKbCUzV7nmZjudxSEBsrABXQDm2K78mTthCs2S AEuw5Nn2RWqw+Tsrd+cIvF1ybtTu5IiQJ3GE17q+LML2zpvvwU8zbY3dV14pF2nzLt66 Gwb5Cv3AVpr47fEiKUoJqeaVpM98NNE/1WPLNPg+wfI9HMvhPe/xynxVY3rWFMET9TM9 9YmA== X-Gm-Message-State: AIkVDXLNcfaM0ucxFveg5E2tzFnA0lZHBGP8BW3I/cPpbK51hAYbLpH8mRN5rIj50y520shV X-Received: by 10.98.147.207 with SMTP id r76mr42582415pfk.111.1485298244394; Tue, 24 Jan 2017 14:50:44 -0800 (PST) Received: from ?IPv6:2620::10e7:10:646a:f84e:6f4:3c12? ([2620:0:10e7:10:646a:f84e:6f4:3c12]) by smtp.gmail.com with ESMTPSA id f188sm39019502pfa.35.2017.01.24.14.50.43 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 24 Jan 2017 14:50:43 -0800 (PST) From: james woodyatt Content-Type: multipart/alternative; boundary="Apple-Mail=_DA845027-C0FA-4538-BCCE-6E0655796857" Message-Id: <75027399-7127-4C8D-BAEA-4F3F923EC728@google.com> Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Date: Tue, 24 Jan 2017 14:50:42 -0800 References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <99204933-5CB6-4E89-BD6A-FD40136DF6F5@steffann.nl> <64592AC1-EFE9-4AA9-8C94-CF48986EC485@google.com> <892E650B-5F77-4FB9-B157-B84300E15CF6@fugue.com> <672582C8-BE04-4CF1-B26E-E8CF3235F6DB@google.com> To: IPv6 Ops WG In-Reply-To: X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [v6ops] sidetrack on DNS-SD vs. DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2017 22:50:46 -0000 --Apple-Mail=_DA845027-C0FA-4538-BCCE-6E0655796857 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jan 24, 2017, at 02:20, Philip Homburg = wrote: >=20 > However the way you describe it, you need DHCPv6 at least for host = specific=20 > configuration unless all hosts implement a new configuration protocol. > Which would bring the total number to 4 (RA, DHCPv6, DNS-SD, and an > undisclosed per host configuration protocol). That=E2=80=99s not my position. My position is that, ideally, you = shouldn=E2=80=99t need to provide host-specific configuration before = completing the network attachment process during which valid interface = addresses are assigned. In shorter terms, you should need neither DHCPv6 nor a similar protocol. You should be able to complete the network attachment process entirely = with ICMPv6 Neighbor and Router Discovery interactions. If hosted = applications, including certain high-level operating system services, = require individual configuration parameters customized for each instance = on the network, then those application instances should not use DHCP as = their configuration protocol. That=E2=80=99s my ideal world. I realize = the actual world has to be considerably messier for political and = economic reasons. > In that world, it makes way more sense, both for host operating = systems and > network operators to completely ignore DNS-SD and stick to RA and = DHCPv6. > (And publish an RFC that makes implementing both RA and DHCPv6, = including=20 > IA_NA mandatory) Disagree. Every technical argument I=E2=80=99ve seen put forward to = explain the architectural need for IA_NA is unconvincing to me. Only the = political and economic arguments have ever been persuasive for me. For = that reason, I=E2=80=99d strongly oppose making IA_NA a mandatory = capability of IPv6 hosts. --james woodyatt > --Apple-Mail=_DA845027-C0FA-4538-BCCE-6E0655796857 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Jan 24, 2017, at 02:20, Philip Homburg <pch-v6ops-6@u-1.phicoh.com> wrote:

    However the way you describe it, you need DHCPv6 = at least for host specific 
    configuration unless all hosts implement a new = configuration protocol.
    Which would bring the total number to 4 = (RA, DHCPv6, DNS-SD, and an
    undisclosed per host = configuration protocol).

    That=E2=80=99= s not my position. My position is that, ideally, you shouldn=E2=80=99t = need to provide host-specific configuration before completing the = network attachment process during which valid interface addresses are = assigned.

    In shorter terms, you = should need neither DHCPv6 nor a similar protocol.

    You should be able to complete the network = attachment process entirely with ICMPv6 Neighbor and Router Discovery = interactions. If hosted applications, including certain high-level = operating system services, require individual configuration parameters = customized for each instance on the network, then those application = instances should not use DHCP as their configuration protocol. That=E2=80=99= s my ideal world. I realize the actual world has to be considerably = messier for political and economic reasons.

    In that world, it makes way more sense, = both for host operating systems and
    network operators to completely = ignore DNS-SD and stick to RA and DHCPv6.
    (And publish an RFC that makes = implementing both RA and DHCPv6, including 
    IA_NA mandatory)

    Disagree. Every technical argument I=E2=80=99ve = seen put forward to explain the architectural need for IA_NA is = unconvincing to me. Only the political and economic arguments have ever = been persuasive for me. For that reason, I=E2=80=99d strongly oppose = making IA_NA a mandatory capability of IPv6 hosts.

    --james woodyatt <jhw@google.com>



    = --Apple-Mail=_DA845027-C0FA-4538-BCCE-6E0655796857-- From nobody Tue Jan 24 16:35:34 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9991295D4 for ; Tue, 24 Jan 2017 16:35:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 yyeDf-nW2zXB for ; Tue, 24 Jan 2017 16:35:31 -0800 (PST) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BEA81295D1 for ; Tue, 24 Jan 2017 16:35:30 -0800 (PST) Received: by mail-wm0-x231.google.com with SMTP id f73so47288459wmf.1 for ; Tue, 24 Jan 2017 16:35:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1IJpwYW54BgNguvsEB8Hyszb6Uc+MkCIOfXmZhWJ7L0=; b=oO4t2oat8TcE35niTta9yv/w5i4IL1eG8H+MrgwVAHVKWDKxlCizAOQTeyCVc89/Mm I5fFbOPPP3sfDWZfu13F6xFnQlnaduhpoRpLWdJrhc4RgQjChPDzBIXyNQwkerQ/0Trs ChviRB/IhUaE6xLLWrAh6VyStQhct3Kr9xqSU41JGFM9CVI5EphDr92xkZhDlybzSix7 5Xcr+7xF3l8LTlWHInA7l+7eZ5uiUDvO5PN9teKCglkxrB3ZQ5j8ZmZV13X7JQopTupD 9Ova02mFtS6CFjeqsL7UDaaZEd3Pchp6j0OpBFA8CrgztPZ1Lstgo92RKFXd7K0uHzSf qhxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1IJpwYW54BgNguvsEB8Hyszb6Uc+MkCIOfXmZhWJ7L0=; b=m56PbbGT4afo2ExXFX/v5Qcdk01iRpzXYuSCnEbUQuU66cd/OIxdRtfJyqy4P6G1jI QJzN7gOsLwLtJFbQJeJlYU+6wu9WC8R0l/m3+290mpU3qU5fP4QCyH+rp/Bm7VnL8NOG IOT2zonn7MoksFeVMbVaLGEF9RDNBLQYAK3webwSkhaFntcRf/OhkL+DpLa8n3+FhA4C gOhEgxnAt88dWeEy5Ujw8fq3Vr/tp1oE35ZVq7mPW7nq9PXClBYdfzH38RqX2KDpmThb VN90Cx/MdhVUdR9hmLnzY8qERIz6U5L4TWX10MMFgWol/pdysmMxuceZiV67JhBvPlU/ WVuw== X-Gm-Message-State: AIkVDXKzIAeYvbTOCjXfa8wau/IOQRWrVP9Prc7LxXX80oi+x5VH0QHGpUR4hNXqXerreYfLrv/8wPe8GetsSbhh X-Received: by 10.28.134.67 with SMTP id i64mr19311353wmd.5.1485304528822; Tue, 24 Jan 2017 16:35:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.196.207 with HTTP; Tue, 24 Jan 2017 16:35:08 -0800 (PST) In-Reply-To: <75027399-7127-4C8D-BAEA-4F3F923EC728@google.com> References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <99204933-5CB6-4E89-BD6A-FD40136DF6F5@steffann.nl> <64592AC1-EFE9-4AA9-8C94-CF48986EC485@google.com> <892E650B-5F77-4FB9-B157-B84300E15CF6@fugue.com> <672582C8-BE04-4CF1-B26E-E8CF3235F6DB@google.com> <75027399-7127-4C8D-BAEA-4F3F923EC728@google.com> From: Erik Kline Date: Wed, 25 Jan 2017 09:35:08 +0900 Message-ID: To: james woodyatt Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a11441294d719f90546e068be" Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] sidetrack on DNS-SD vs. DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 00:35:32 -0000 --001a11441294d719f90546e068be Content-Type: multipart/alternative; boundary=001a11441294d31b6d0546e068e9 --001a11441294d31b6d0546e068e9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > > Disagree. Every technical argument I=E2=80=99ve seen put forward to expla= in the > architectural need for IA_NA is unconvincing to me. Only the political an= d > economic arguments have ever been persuasive for me. For that reason, I= =E2=80=99d > strongly oppose making IA_NA a mandatory capability of IPv6 hosts. > Agreed. --001a11441294d31b6d0546e068e9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Disagree. Every technical argument I=E2=80=99ve seen put forward = to explain the architectural need for IA_NA is unconvincing to me. Only the= political and economic arguments have ever been persuasive for me. For tha= t reason, I=E2=80=99d strongly oppose making IA_NA a mandatory capability o= f IPv6 hosts.

    Agreed.
    --001a11441294d31b6d0546e068e9-- --001a11441294d719f90546e068be Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMf7MhR+6WMlT9cAZ4MA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE2MTEyMjA2MzcwNloXDTE3MDUy MTA2MzcwNlowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAMFGbCvV+u+in+H0HY3bqCemHVO+gk8MSoSt5cw8MyfvalJUBE+K8i0L KO7g5Tf0Hwxwin3Y78Fjurdr5ScXC3q2XKlu/KeOcKZ629BIHXR3Bc4P1kbeSBqtdP1hQsXutC3N LKA6HYfEAKX5La7jHPIPymFuzHi9jqRt1XPLBhUIx/BUgV2RaLkaLlKi1gilVaUzZ/bwKGEBPXd7 oqEa0bmYHg7nnH3c07Ka5FqwYFbFNH2B8N9qhsEvaidSWAYFR3c83MxaNvd0cc9VR+xkg4h9t4j8 kgMqch9g5WsqvEiB8X9avk0RfRrJXnLpGVE9SgWC+9g/4qHF7INLnWGpoGsCAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBRSp79TZtpx4DfF6E+LlflJ0/FBvzAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAYNw4ea3dhqz3+6k7eFLEAto3ynoX iT5jeLl+/a9UeVSG5MQjruVO3LeqKKs3757hNcyfMZSooiOzamgE/W2G7gZMkCoT2NQbD7zSNB+S toUONsMQ8t6Awv9osq1WWoK/xZkHV8wMGDOun9Ia8vO+hOU5wMOnhvg5mbE1xbst7pK2P9HgFxY2 /5o3VcBn4M6T5omuaz6GVsQ4VssAWfnqVpholf+EQahap+3Fpue24kwL3/pWnDkp0UcvjfItSy9c UZdf/XOjI7X4DzroB3PFZ+rJSoRUjF2mKCLbHO0TLXtpEpr8ngGu8WwEAwf7eGHI6O5LCxrLYRdw jqaGMxZnxTGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDH+zIUfuljJU/XAGeDAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgd5xWlt9H5168loHxkq+GuaboiKTU/PXI ZukqBIrjBCkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMTI1 MDAzNTI5WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBAJlWXDLwjdEji9qPpr3Bevfslvx6sZBWR/FZ/svhPkDGxC5J0rlX 2qfU6Nbn8vrmzrhaMGGwr+9JbKA3wo5H2HNYN3QwuszaN4bFnXSvspl8LmqDPxfhUZCuOUpMUGyL 4uwRpNChI+c2zHMUJ6FNJ6XZCigsW422ezgqpLxdyocLSz8E6rYX+r21Dxn6CZbjKZe221aKuycr UL8IpWbGu+0KIrW1Q2s/ykRucNAPYLuKA/1jqEkmnlzRXr9hDBChUvPncSAFWu0wIV/tl+NGK3nN ODLBiUjzJZvJ/YSkQmTLjXDLkMqj6eijNraKRzatYBJXCLNJYgYPjtf0giCqvWY= --001a11441294d719f90546e068be-- From nobody Thu Jan 26 10:45:37 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FAB312997A for ; Thu, 26 Jan 2017 10:45:35 -0800 (PST) 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 3CncLGfVhqCb for ; Thu, 26 Jan 2017 10:45:34 -0800 (PST) Received: from mail-pg0-x241.google.com (mail-pg0-x241.google.com [IPv6:2607:f8b0:400e:c05::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDD4D129972 for ; Thu, 26 Jan 2017 10:45:33 -0800 (PST) Received: by mail-pg0-x241.google.com with SMTP id 204so22961143pge.2 for ; Thu, 26 Jan 2017 10:45:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mRGuRoi01OOL6cV1hoFK/FYbkoAK8RhR/877FAL5Yiw=; b=DM7CMWSlR58PiuR1yKnTa8DexxaYPNGlGv2X7X4o5Xmky7WNyb0MvYNLNrd9tFMSsz pcF+LfmecoMTESxBF+MjvL/GWp0svh7YW1SmH7GtilUyaad79dY1zYyLzXwXyJP0WzTU 2J1adoqb4fCQTEAiMNReLPoYI186pstEyjIgu7hlKnV+mx6ofuZqFlOVv/hbxLicfC+8 ItMjwsz++dqCKqSem/iKXupWYRxGHkh3zlKH9+fHiuwL0K3PTAOPYN3xxAe1gkKtewxd xyR69eeA4FZR8DwTEPclelXlSYZuVM51GFjqDuPFNfc8QHHwZGKYDYqm7AhUZmpZDDG0 NE7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mRGuRoi01OOL6cV1hoFK/FYbkoAK8RhR/877FAL5Yiw=; b=YbXEDrRbD9CRs6VagbLMoc9iv3lNaGDpX17JIU1PyTAmkbg8cvCobqVlitQtgGIilY b+ZWEBxCkuR0qOpYNpJNydWJjWxuRHe9cZNHW3m1FqcGjnpT6n/SxsW5ycchgcBL2NgN XqbgzCNMtA+3pSfw6XW5xjZeQqmwqWphUGX1PiNOycM3M2rXofaAYnhToED2MndKWQtH PIbAJ4QRQO+1Tslf2yV4kKaHmChloziVMqoyDItXJj0EGHiKW0OIBaswg+D7j5nCV0fW W/6Z/Wi9f81xFwGic48vMA84ELzNRDS+UCMGp7BNngIHS2qWlFbH/+v2RP6csA7X21pV ru0g== X-Gm-Message-State: AIkVDXKSJwf/22ywyb+3AxsX6M6h9nzEYFBKJv8/dRP2lWaVq2/BD9Rd9iKMBMfRacBLXw== X-Received: by 10.84.173.4 with SMTP id o4mr6255612plb.106.1485456333466; Thu, 26 Jan 2017 10:45:33 -0800 (PST) Received: from ?IPv6:2600:8801:d004:600:bda9:a9ba:e848:ac4a? ([2600:8801:d004:600:bda9:a9ba:e848:ac4a]) by smtp.gmail.com with ESMTPSA id g28sm5156258pgn.3.2017.01.26.10.45.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Jan 2017 10:45:32 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Fred Baker In-Reply-To: <75027399-7127-4C8D-BAEA-4F3F923EC728@google.com> Date: Thu, 26 Jan 2017 10:45:30 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <99204933-5CB6-4E89-BD6A-FD40136DF6F5@steffann.nl> <64592AC1-EFE9-4AA9-8C94-CF48986EC485@google.com> <892E650B-5F77-4FB9-B157-B84300E15CF6@fugue.com> <672582C8-BE04-4CF1-B26E-E8CF3235F6DB@google.com> <75027399-7127-4C8D-BAEA-4F3F923EC728@google.com> To: james woodyatt X-Mailer: Apple Mail (2.3259) Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] sidetrack on DNS-SD vs. DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2017 18:45:35 -0000 On Jan 24, 2017, at 2:50 PM, james woodyatt wrote: > On Jan 24, 2017, at 02:20, Philip Homburg = wrote: >> In that world, it makes way more sense, both for host operating = systems and >> network operators to completely ignore DNS-SD and stick to RA and = DHCPv6. >> (And publish an RFC that makes implementing both RA and DHCPv6, = including=20 >> IA_NA mandatory) >=20 > Disagree. Every technical argument I=E2=80=99ve seen put forward to = explain the architectural need for IA_NA is unconvincing to me. Only the = political and economic arguments have ever been persuasive for me. For = that reason, I=E2=80=99d strongly oppose making IA_NA a mandatory = capability of IPv6 hosts. I would guess that we're discussing the difference between technical = requirements and market requirements. Technically, the requirement is = that an implementation provide a way in which the host can attach to the = network, and in which it can derive the remaining information it needs = to do its job. Depending on the market, I can see SLAAC and DHCPv6 as = each meeting the viewpoints of operators. I'd be interested to know the = target operational market for DNS-SD: who is asking for the capability?=20= Personally, while listing capabilities that we think should go into = various kinds of equipment is interesting, I tend to think of it as = highly political. If a person is politically inclined in the DHCP = direction (pick a reason), SLAAC seems pretty optional. If a person is = politically inclined toward SLAAC, DHCP seems irrelevant. The reason = they both exist is because each has a market, a set of operational = environments in which it is viewed as a technical requirement. If anything, I might suggest identifying and discussing the requirements = of various markets. If an implementor - a vendor, an open source = developer, or whatever - wants to deploy in a given market, that would = give them the requirements of that market.= From nobody Thu Jan 26 11:12:02 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8D111299AB for ; Thu, 26 Jan 2017 11:12:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 2CKumyWCxPwp for ; Thu, 26 Jan 2017 11:11:52 -0800 (PST) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FE241299A5 for ; Thu, 26 Jan 2017 11:11:52 -0800 (PST) Received: by mail-pf0-x233.google.com with SMTP id 189so67335239pfu.3 for ; Thu, 26 Jan 2017 11:11:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=CwoPQLAV3EDgkogQ/BPjFTXhxlYMtGSa1LcBkcF+t1M=; b=RvoEhuU2OzaHISA2T8+jF1VT9/BVbUBIOc9C5O+4HlN5UKG48wo/Qj0s7ZZP+6drPp JPI6jKsiXS4WzKBvUNPbW4UxGAADE6GbmYEj1vaYa5hvkAMf+guY1GzHeJpSi7pWtXEQ VmOU5imsaqDzEVHxEgw8b3rwDtomGTb8XkgmAUT00IPPfJNkQ15iqGycUOrAfnP0Mml2 r6BD93qfHhHmqxY9nEEWshPub2s099jt8LsdXywYvTZR1T1KHGDdWG6ivcXnYOzPb6YT HvJ76lo1Zb1t4JOUBZZjCXoBCV3c0HccnBydXNui9uSY1hvAsTuiLd7inxn9eh/SHE7Q glAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=CwoPQLAV3EDgkogQ/BPjFTXhxlYMtGSa1LcBkcF+t1M=; b=M52Txh3gh0dLEtRXVJmOiJWZAPrZmZ/AGjFrEJA6YyGUT6CYawr7EzayqDO6bSctEH zGorS49yFJ1cKfU0iUHyRZa2DwonmXrukjwuszcaY5UDsbdOzMhzZ6fzGoiTJM1h1wTf h5cckNMQ22vF7seMprHopk0cOlv89AGCLv2mRd51g87sMTBATrtli/2z4TSVNN5QC4VX w3nnS+EvSZJqq6CmGs3F+tS5buybclwsXO/Rj8Q3C5a0l3L67bOhWPu0N6cnbPq9fMRa ouggjksooRPKI4hPWRK9GAJXb3fZe9937hvtIvBppH5fVV8QnOXucdrnfeor5NzJpa70 MmKQ== X-Gm-Message-State: AIkVDXLjYr8/ziuVo98zHWf90htdPQ1ORR9H4jNo5kh4RUkprvqDmp+yR/jTD4stNf5ebw== X-Received: by 10.84.143.203 with SMTP id 69mr6373712plz.68.1485457911752; Thu, 26 Jan 2017 11:11:51 -0800 (PST) Received: from [192.168.178.26] ([118.148.115.230]) by smtp.gmail.com with ESMTPSA id h4sm5226529pfk.96.2017.01.26.11.11.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Jan 2017 11:11:51 -0800 (PST) To: Fred Baker , james woodyatt References: <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <99204933-5CB6-4E89-BD6A-FD40136DF6F5@steffann.nl> <64592AC1-EFE9-4AA9-8C94-CF48986EC485@google.com> <892E650B-5F77-4FB9-B157-B84300E15CF6@fugue.com> <672582C8-BE04-4CF1-B26E-E8CF3235F6DB@google.com> <75027399-7127-4C8D-BAEA-4F3F923EC728@google.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <451d7886-d6bc-0560-8782-5e2751a3e1aa@gmail.com> Date: Fri, 27 Jan 2017 08:11:57 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] sidetrack on DNS-SD vs. DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2017 19:12:01 -0000 On 27/01/2017 07:45, Fred Baker wrote: ... > If a person is politically inclined in the DHCP direction (pick a reason), SLAAC seems pretty optional. If a person is politically inclined toward SLAAC, DHCP seems irrelevant. The reason they both exist is because each has a market, a set of operational environments in which it is viewed as a technical requirement. So, surely *our* job is to ensure that the various standards are mutually consistent, and complete enough to support both inclinations. I view the value of the draft in question (draft-ietf-v6ops-dhcpv6-slaac-problem if everyone's forgotten) being to identify inconsistencies. The question of completeness also needs to be analysed. Brian From nobody Thu Jan 26 11:16:46 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11CCD12999E for ; Thu, 26 Jan 2017 11:16:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Bes1uRmxQUu2 for ; Thu, 26 Jan 2017 11:16:37 -0800 (PST) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 833D212999C for ; Thu, 26 Jan 2017 11:16:37 -0800 (PST) Received: by mail-pg0-x22f.google.com with SMTP id 3so15961495pgj.3 for ; Thu, 26 Jan 2017 11:16:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6RGO9YIlcIaex4gC6StQCyPybK4N2+bfJrdN0ox4sVU=; b=j/Xo7QvuqxMOiB4AXzr7bnyx4b0hUlBDVCcqC7x6SmrUjygYT72F4T7ET7Anzftf3Z 6bQKXjsih8uRo3guoRnfW9yEs9kNNpB/Ad+HB74uXv0AO1M2bZ1uXrbiVQagmr+D7PVI McjHC3F+UZRX0EGv6ThW7wl2TpjqBFMHHs/ZrRXmBTe5t5KBN2ScRqMmztO3qzn59csJ 5ftlZEhQXGOKGydN/MufJNzTXIVik4V1cDtdnKWIpAN9tiTVPEzfKGN93CmdoeV1vgLc 9fMIFYnbWaF22HBz0s0xzaxKjlHeozsIIonDirr2fvFwvhmpVnhPbywHZaACLycJyZ0l o9/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6RGO9YIlcIaex4gC6StQCyPybK4N2+bfJrdN0ox4sVU=; b=EToiirTqyGw199cA1qAehWtPWn6wM/cArQ3Lncg40EbHkcysEt8nqo8dTsgF7R+kNE W2jmmWFTcQeRQnbO7eqZ35FbiyHT8los/x9dOKngp6vxToaqQ6UGN28RAo+o0OVv53Iw m8Sv/y5AsEo72I0iR/uHkbiDDDnxkPz9joT0NufycVWrlpq/sJWSCGTASi1qHtuiVRfr V2vgSqFwWFH8ca0TlK0X/eiiTmnJjtR3HqdAl25H6hCiu7EyP1pKSJAsgRzNjY1p4O4Q Z3N+2hEEaEaR2UjdawOW/SooD0bzfhmtinFgL3xhEUOOi2FBflDzA3lJpEk7Ivo1j+Xe DPXQ== X-Gm-Message-State: AIkVDXKbEhT0y4Igre/Q3RNXzkjbzijVrNdAiJLwO8z/9vM87lfJVFyhLwd+DhTxOAubiQ== X-Received: by 10.99.125.17 with SMTP id y17mr4992958pgc.27.1485458197181; Thu, 26 Jan 2017 11:16:37 -0800 (PST) Received: from ?IPv6:2600:8801:d004:600:bda9:a9ba:e848:ac4a? ([2600:8801:d004:600:bda9:a9ba:e848:ac4a]) by smtp.gmail.com with ESMTPSA id w76sm5251835pfd.74.2017.01.26.11.16.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Jan 2017 11:16:36 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Fred Baker In-Reply-To: <451d7886-d6bc-0560-8782-5e2751a3e1aa@gmail.com> Date: Thu, 26 Jan 2017 11:16:34 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <8DC8EC71-543A-4B56-963B-219075BF0BBA@gmail.com> References: <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <99204933-5CB6-4E89-BD6A-FD40136DF6F5@steffann.nl> <64592AC1-EFE9-4AA9-8C94-CF48986EC485@google.com> <892E650B-5F77-4FB9-B157-B84300E15CF6@fugue.com> <672582C8-BE04-4CF1-B26E-E8CF3235F6DB@google.com> <75027399-7127-4C8D-BAEA-4F3F923EC728@google.com> <451d7886-d6bc-0560-8782-5e2751a3e1aa@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3259) Archived-At: Cc: james woodyatt , IPv6 Ops WG Subject: Re: [v6ops] sidetrack on DNS-SD vs. DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2017 19:16:39 -0000 > On Jan 26, 2017, at 11:11 AM, Brian E Carpenter = wrote: >=20 > On 27/01/2017 07:45, Fred Baker wrote: > ... >> If a person is politically inclined in the DHCP direction (pick a = reason), SLAAC seems pretty optional. If a person is politically = inclined toward SLAAC, DHCP seems irrelevant. The reason they both exist = is because each has a market, a set of operational environments in which = it is viewed as a technical requirement. >=20 > So, surely *our* job is to ensure that the various standards are = mutually > consistent, and complete enough to support both inclinations. I view = the > value of the draft in question (draft-ietf-v6ops-dhcpv6-slaac-problem = if > everyone's forgotten) being to identify inconsistencies. The question = of > completeness also needs to be analysed. Pretty much.= From nobody Thu Jan 26 11:29:23 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E8721299CE for ; Thu, 26 Jan 2017 11:29:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 eXrPObw7uOPA for ; Thu, 26 Jan 2017 11:29:19 -0800 (PST) Received: from mail-yb0-x235.google.com (mail-yb0-x235.google.com [IPv6:2607:f8b0:4002:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE6111299C2 for ; Thu, 26 Jan 2017 11:29:19 -0800 (PST) Received: by mail-yb0-x235.google.com with SMTP id f67so51285436ybc.2 for ; Thu, 26 Jan 2017 11:29:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Cy7P0EAC/lycieaCtCMJkA2X2fRc/a4x/UPLIbKoy6Y=; b=10tS3+C+7jbQyj/RUQCe2sshwq0jB57rR4/wM/QbNolkJqvikiZoNyoNXtYgU9MnrE YCSIjreuMMqczdNVzA4qpERHTVeRdSLLunqTKAcUlOj9wEhzJO2aQAvGaJ8NV08BWXFT wyljLZOZYyIik9xGRB2dF97trxg7G86Nv3k8iT88z7UYD/HZ4UgFFapyiyb8pm2B6Xlz jkorsCoGo8/sU6P8LSkubjvzVLkffBqgrYcaNEOsXJaf8i1rShCThOQQXdmZK2fEeWr8 8xD2EfnbEpx8ePQawNNGWpj2wa7JdaUbc8UrAziYqrLoG3R//MjyMehqsz8fJLQ5/Tly ER5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Cy7P0EAC/lycieaCtCMJkA2X2fRc/a4x/UPLIbKoy6Y=; b=JSMcPTxLwVhN7GhHOpkQUr+4pSNF14F4qrXFByvMvhWsy351D7lWKfrcVmQC2J81ZQ zrJqerFrz3e93vx5CLolSS8YI/9ZT9tXJsiPZOzHzweguRpLC1Jp+iK2emGGtZRTSqc1 y8Sleh47bmoFFpEEhDTEvVDc8ad7vqJkAllx0H7C1AyGY6HfB9j8wjqhmDJE6lW1qbqR HJ14g5BrfAKc0Lh4w8yiVrGwMhKJUUbq+9tY1HDwzMIr0x9BeX4Y2dNNvY3zwqlevxFT eHrlsM+ceMBq3Dksp+RXWfSsJRU5NKB3TyCBahCSCNLH/04L9FU/BbbmFHEnS3pjVpDz uMYg== X-Gm-Message-State: AIkVDXL32zYB6RcgtrBBkvFs4X7J+uj6zPCi5rQmy/E/7DPGI2C8YTfbuDwJDUTeAnNdyA== X-Received: by 10.55.152.4 with SMTP id a4mr4377661qke.69.1485458959109; Thu, 26 Jan 2017 11:29:19 -0800 (PST) Received: from [192.168.1.228] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id m12sm1987974qtm.45.2017.01.26.11.29.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Jan 2017 11:29:18 -0800 (PST) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_1FD3E5C9-4E7F-4EFE-9498-A639B43D0AD6" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Thu, 26 Jan 2017 14:29:16 -0500 In-Reply-To: To: Fred Baker References: <8e76ec91-9c4f-4dca-6a67-51834e60c16a@si6networks.com> <6d448366-67af-8b65-af0e-4418ff427aab@si6networks.com> <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <99204933-5CB6-4E89-BD6A-FD40136DF6F5@steffann.nl> <64592AC1-EFE9-4AA9-8C94-CF48986EC485@google.com> <892E650B-5F77-4FB9-B157-B84300E15CF6@fugue.com> <672582C8-BE04-4CF1-B26E-E8CF3235F6DB@google.com> <75027399-7127-4C8D-BAEA-4F3F923EC728@google.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: james woodyatt , IPv6 Ops WG Subject: Re: [v6ops] sidetrack on DNS-SD vs. DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2017 19:29:22 -0000 --Apple-Mail=_1FD3E5C9-4E7F-4EFE-9498-A639B43D0AD6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jan 26, 2017, at 1:45 PM, Fred Baker = wrote: > I'd be interested to know the target operational market for DNS-SD: = who is asking for the capability?=20 There was a petition from EDUCAUSE. But more broadly, any environment in which we want to be able to plug a = printer into the network and then print on it from hosts without typing = in a manual configuration somewhere. --Apple-Mail=_1FD3E5C9-4E7F-4EFE-9498-A639B43D0AD6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Jan 26, 2017, at 1:45 PM, Fred Baker <fredbaker.ietf@gmail.com> wrote:
    I'd be interested = to know the target operational market for DNS-SD: who is asking for the = capability? 

    There was a petition from = EDUCAUSE.

    But = more broadly, any environment in which we want to be able to plug a = printer into the network and then print on it from hosts without typing = in a manual configuration somewhere.

    = --Apple-Mail=_1FD3E5C9-4E7F-4EFE-9498-A639B43D0AD6-- From nobody Fri Jan 27 02:53:06 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1140712949A for ; Fri, 27 Jan 2017 02:53:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=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 qq0mqaj8CLoW for ; Fri, 27 Jan 2017 02:53:03 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id F3FC8129495 for ; Fri, 27 Jan 2017 02:53:01 -0800 (PST) Received: from stereo.hq.phicoh.net ([::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #127) id m1cX49L-0000DdC; Fri, 27 Jan 2017 11:52:59 +0100 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bF054DD66@u-1.phicoh.com References: <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <99204933-5CB6-4E89-BD6A-FD40136DF6F5@steffann.nl> <64592AC1-EFE9-4AA9-8C94-CF48986EC485@google.com> <892E650B-5F77-4FB9-B157-B84300E15CF6@fugue.com> <672582C8-BE04-4CF1-B26E-E8CF3235F6DB@google.com> <75027399-7127-4C8D-BAEA-4F3F923EC728@google.com> <451d7886-d6bc-056 0-8782-5e2751a3e1aa@gmail.com> In-reply-to: Your message of "Fri, 27 Jan 2017 08:11:57 +1300 ." <451d7886-d6bc-0560-8782-5e2751a3e1aa@gmail.com> Date: Fri, 27 Jan 2017 11:52:58 +0100 Archived-At: Subject: Re: [v6ops] sidetrack on DNS-SD vs. DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2017 10:53:05 -0000 In your letter dated Fri, 27 Jan 2017 08:11:57 +1300 you wrote: >I view the >value of the draft in question (draft-ietf-v6ops-dhcpv6-slaac-problem if >everyone's forgotten) being to identify inconsistencies. The question of >completeness also needs to be analysed. I'd say a network operator SHOULD make sure information in RA and DHCPv6 is consistent. Hosts are allowed to use an unspecified selection algorithm do decide what to use if there are inconsistencies. This should be the starting point. If there is a clear operational need why RA and DHCP have to be inconsistent. Then we should document that need and how hosts should respond. By and large trying to enumerate every possible way RA and DHCP can be inconsistent doesn't strike me as very productive. And for some things, like renumbering from RA to DHCP, try not to shoot yourself in the foot. From nobody Sun Jan 29 16:43:46 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01BA112009C for ; Sun, 29 Jan 2017 16:43:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.308 X-Spam-Level: X-Spam-Status: No, score=-0.308 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 IBZg-YimHV6N for ; Sun, 29 Jan 2017 16:43:42 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53026129853 for ; Sun, 29 Jan 2017 16:43:42 -0800 (PST) Received: from [192.168.3.90] (142-135-17-190.fibertel.com.ar [190.17.135.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id B3B23828DB; Mon, 30 Jan 2017 01:43:37 +0100 (CET) To: Fred Baker , james woodyatt References: <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <99204933-5CB6-4E89-BD6A-FD40136DF6F5@steffann.nl> <64592AC1-EFE9-4AA9-8C94-CF48986EC485@google.com> <892E650B-5F77-4FB9-B157-B84300E15CF6@fugue.com> <672582C8-BE04-4CF1-B26E-E8CF3235F6DB@google.com> <75027399-7127-4C8D-BAEA-4F3F923EC728@google.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: Date: Sun, 29 Jan 2017 18:17:51 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] sidetrack on DNS-SD vs. DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2017 00:43:44 -0000 On 01/26/2017 03:45 PM, Fred Baker wrote: > > On Jan 24, 2017, at 2:50 PM, james woodyatt wrote: >> On Jan 24, 2017, at 02:20, Philip Homburg >> wrote: [....] > > Personally, while listing capabilities that we think should go into > various kinds of equipment is interesting, I tend to think of it as > highly political. If a person is politically inclined in the DHCP > direction (pick a reason), SLAAC seems pretty optional. If a person > is politically inclined toward SLAAC, DHCP seems irrelevant. The > reason they both exist is because each has a market, a set of > operational environments in which it is viewed as a technical > requirement. Unfortunately, one way or another, both are mandatory in practice, since you need the *two* of them to be able to support the most popular devices. And that's really bad. > If anything, I might suggest identifying and discussing the > requirements of various markets. If an implementor - a vendor, an > open source developer, or whatever - wants to deploy in a given > market, that would give them the requirements of that market. Requirements: do both DHCPv6 and SLAAC. because in practice non of them can be employed to provide the most basic info (and address, a default route, and a caching DNS server), bacause of religious wars on which major vendors think they know better than the others. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sun Jan 29 17:39:18 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 406DD1298D2 for ; Sun, 29 Jan 2017 17:39:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 rkeX_SxibzeI for ; Sun, 29 Jan 2017 17:39:15 -0800 (PST) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4AE11298CF for ; Sun, 29 Jan 2017 17:39:14 -0800 (PST) Received: by mail-qk0-x22e.google.com with SMTP id j126so96343183qkf.1 for ; Sun, 29 Jan 2017 17:39:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=RDXIaRcxhQjBhyHLapfO6tYgFjElv+72ajept495vqA=; b=ZAS9tILyV8p6Cu9cvgbf6RNKOUZBW9lOI1ZnpcQHZuEOWF+i6WSi11qGLxjJjWQz6B HEqWIptxpOxv8+iKByWrb+PgOp8mEv9kSFQSyVcMaRVtaAxN+zVcj8Q86EIukZD0UgE9 5kd3WdXEJ+QI6O5hpd0N97DFsg78geJJGEX0+DlGtzt6X7SKhBydlY5iVH97dG8lymKe rAsYqKKY6XVph0uUV1WFGdmmRBf+IxTW0OAUb+amaVte6f41gB6GfNoxnm0ekhYc5jLa lZUd9xtHKSQZIe4FFLfDPa1qpfGeKEIsd5+vtbW+xXdft8vf6Pb7vPADHHQ9zIcfffwg Pocg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=RDXIaRcxhQjBhyHLapfO6tYgFjElv+72ajept495vqA=; b=QxvZPPZYm1cWWWaUukyWH8hlI5VeBuSASQlGDIp2bSmivxrAR+CwFArkCgA0TLUIbY 10cA5SyGmhmU3b4QUUWSHvEpoTv28pcpfkoWfmuupPYuj7lbWjywBsMN0vAkUDPEeErv aTw1o/iiNxJH5RKyfJ5epHwvq3qOvRRwYoFebSk1d4EWIMFcgxwzW5qKfR+PxMHIDvEY K/3BHaZI2j5NtTsjzYh2mTCvGUVAdAb76tfRmi6/3PY4Q+xRU6qAVAeDGcytkTkv0TlG gMOEjk0HzgE8Fzi9u5VbnSpKN4Y/CHvE7R8arvQPnv90kPXjOu2ngSJKt4PHWXKGlGme W+Bw== X-Gm-Message-State: AIkVDXJjd83oatD7VnUxVgFySFjvsTJPip53c2lmTT/nNlOoACjRAJR89l2GVojHX1k5QQ== X-Received: by 10.55.9.15 with SMTP id 15mr19278316qkj.118.1485740354083; Sun, 29 Jan 2017 17:39:14 -0800 (PST) Received: from [192.168.1.228] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id e3sm10741796qtg.7.2017.01.29.17.39.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 29 Jan 2017 17:39:12 -0800 (PST) From: Ted Lemon Message-Id: <43AB38C9-B4D8-4499-BA6F-B0C668F10554@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_839CA07C-67EC-4EBA-A24B-A8C3168D773A" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Sun, 29 Jan 2017 20:39:10 -0500 In-Reply-To: To: Fernando Gont References: <965F57AB-1807-4480-9025-520D587A612A@fugue.com> <4e36cb0f-c5dd-cdba-ce63-09ab735cdd9d@si6networks.com> <99204933-5CB6-4E89-BD6A-FD40136DF6F5@steffann.nl> <64592AC1-EFE9-4AA9-8C94-CF48986EC485@google.com> <892E650B-5F77-4FB9-B157-B84300E15CF6@fugue.com> <672582C8-BE04-4CF1-B26E-E8CF3235F6DB@google.com> <75027399-7127-4C8D-BAEA-4F3F923EC728@google.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: james woodyatt , IPv6 Ops WG Subject: Re: [v6ops] sidetrack on DNS-SD vs. DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2017 01:39:16 -0000 --Apple-Mail=_839CA07C-67EC-4EBA-A24B-A8C3168D773A Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On Jan 29, 2017, at 4:17 PM, Fernando Gont wrote: > Unfortunately, one way or another, both are mandatory in practice, since > you need the *two* of them to be able to support the most popular > devices. And that's really bad. Because...? --Apple-Mail=_839CA07C-67EC-4EBA-A24B-A8C3168D773A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Jan 29, 2017, at 4:17 PM, Fernando Gont <fgont@si6networks.com> wrote:
    Unfortunately, one = way or another, both are mandatory in practice, since
    you need the *two* of them to be able to support = the most popular
    devices. And that's really = bad.

    Because...?

    = --Apple-Mail=_839CA07C-67EC-4EBA-A24B-A8C3168D773A-- From nobody Tue Jan 31 07:22:59 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80DEF1294CC for ; Tue, 31 Jan 2017 07:22:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.058 X-Spam-Level: X-Spam-Status: No, score=-3.058 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com 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 s4ITxb3zIW5r for ; Tue, 31 Jan 2017 07:22:56 -0800 (PST) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0103.outbound.protection.outlook.com [104.47.34.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCAF71294AC for ; Tue, 31 Jan 2017 07:22:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=1ovZn3qN2/WINUU/2a+Nk/SX7G2sj+YXdcfR908HlnY=; b=aiDQ9CfeG2OGhTZ9w7fn9br/XCLPF2DwsFrX9oBjoC6a7RARL1qPdc8xr9ah8338zz6WaSCOZnAg73IHZwrCY1WYRqGyADRt+DGlQEOFj/zjcBNRWGfYY722wfI0ri/QNGghiulpbSGumjW1wQIcT782qviZwQlRvF4sDv9C954= Received: from BLUPR0501MB2051.namprd05.prod.outlook.com (10.164.23.21) by BLUPR0501MB2051.namprd05.prod.outlook.com (10.164.23.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.874.6; Tue, 31 Jan 2017 15:22:54 +0000 Received: from BLUPR0501MB2051.namprd05.prod.outlook.com ([10.164.23.21]) by BLUPR0501MB2051.namprd05.prod.outlook.com ([10.164.23.21]) with mapi id 15.01.0874.020; Tue, 31 Jan 2017 15:22:54 +0000 From: Ron Bonica To: IPv6 Ops WG Thread-Topic: draft-ietf-v6ops-ula-usage-considerations Thread-Index: AdJ71bub1L6aUKYaSxmQB+Og32Va4w== Date: Tue, 31 Jan 2017 15:22:54 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rbonica@juniper.net; x-originating-ip: [66.129.241.12] x-ms-office365-filtering-correlation-id: 3738396f-facd-4733-4227-08d449ed079c x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BLUPR0501MB2051; x-microsoft-exchange-diagnostics: 1; BLUPR0501MB2051; 7:EPRMqEpeLovVAnX3ci4R8pMNEXliVuesi1viZku83gpvdsO6DEhVkyJT08hfAo0qpc1CE3xshR3CB4yJjGKe0F9T3vj4CvHnk31jLqECF2fzPTwUuUAlt2OdDDtuQs7HX0wdSmrIJMf51/cy8vmlJN1LyhbFVhTE+Fc5nB5ftBSlygMCOtobXAF+Q49V2NRxGe4838uOBt2zl6Y1cmOAQ+KZTEEfHvkQVp7CXJMapqtdYwGb1x//VMCrAwxs5n2cb/LTexvqXHq/lO2GPkuG5Ig0+IGnQXUk+rOP3RsTRqPihOLEqNLmVVp0d1gQM6CbkJOsxtWFeXLL2WwZazT4M5IeXJrS10J9uu+kFZ+BhtWLxNTNt8D8aYFiKspH15lc0DwgLNFoxhCIN8MNmf8hjmv4Z0/yXWUQ2nMEFwwDqBfmKTDSmSY/doBbI1R0yb2xHHduBDxz0SQQpoPGmzUMJVbVo2UktMULTC/pbIlA42YC+uGcT+/1sidCEdf2/5irga/woLFRQKuRXb/DxjA4B/fek16AGZFNqAtL+orlpyK5vw4WUDOwwgFtZvxVj3Fu x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123555025)(20161123560025)(20161123562025)(20161123564025)(6072148); SRVR:BLUPR0501MB2051; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB2051; x-forefront-prvs: 0204F0BDE2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39410400002)(39860400002)(39850400002)(39450400003)(39840400002)(51444003)(189002)(199003)(8936002)(5660300001)(6436002)(50986999)(54356999)(6506006)(25786008)(33656002)(8676002)(38730400001)(6916009)(3660700001)(575784001)(86362001)(77096006)(101416001)(81166006)(74316002)(81156014)(53936002)(99286003)(9686003)(55016002)(6306002)(189998001)(230783001)(110136003)(7736002)(105586002)(7696004)(66066001)(68736007)(6116002)(102836003)(3846002)(2906002)(106356001)(450100001)(2900100001)(3280700002)(107886002)(92566002)(122556002)(97736004)(305945005); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB2051; H:BLUPR0501MB2051.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jan 2017 15:22:54.8590 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB2051 Archived-At: Subject: [v6ops] draft-ietf-v6ops-ula-usage-considerations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 15:22:57 -0000 Folks, Some time ago, I queried the WG's disposition regarding draft-ietf-v6ops-ul= a-usage-considerations (https://mailarchive.ietf.org/arch/search/?email_lis= t=3Dv6ops&index=3Dx6OmZJ1n2F0rBX6iq5GHRBHWRO0&gbt=3D1). I think that the co= nsensus was: - Continue as informational - Recommend against ULA-only - Attempt to find some set of recommendations upon which the WG can agree. So, if the authors are so disposed, I encourage them to produce a new versi= on of the draft, leveraging what we learned during this email thread. Ron From nobody Tue Jan 31 09:42:01 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CFCE129550 for ; Tue, 31 Jan 2017 09:42:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.561 X-Spam-Level: X-Spam-Status: No, score=-0.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_24_48=1.34, SPF_PASS=-0.001] autolearn=no autolearn_force=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 dJnXQAvrlLX4 for ; Tue, 31 Jan 2017 09:41:59 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC0EC129526 for ; Tue, 31 Jan 2017 09:41:58 -0800 (PST) Received: from [192.168.3.82] (142-135-17-190.fibertel.com.ar [190.17.135.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id CAB4B82AD9; Tue, 31 Jan 2017 18:41:54 +0100 (CET) To: Ted Lemon References: <99204933-5CB6-4E89-BD6A-FD40136DF6F5@steffann.nl> <64592AC1-EFE9-4AA9-8C94-CF48986EC485@google.com> <892E650B-5F77-4FB9-B157-B84300E15CF6@fugue.com> <672582C8-BE04-4CF1-B26E-E8CF3235F6DB@google.com> <75027399-7127-4C8D-BAEA-4F3F923EC728@google.com> <43AB38C9-B4D8-4499-BA6F-B0C668F10554@fugue.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: Date: Mon, 30 Jan 2017 03:06:48 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <43AB38C9-B4D8-4499-BA6F-B0C668F10554@fugue.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: james woodyatt , IPv6 Ops WG Subject: Re: [v6ops] sidetrack on DNS-SD vs. DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 17:42:00 -0000 On 01/29/2017 10:39 PM, Ted Lemon wrote: > On Jan 29, 2017, at 4:17 PM, Fernando Gont > wrote: >> Unfortunately, one way or another, both are mandatory in practice, since >> you need the *two* of them to be able to support the most popular >> devices. And that's really bad. > > Because...? Because it essentially implies: * Configuring stuff twice at two different places (prone to error, conflicting information, etc.) -- talk about complexity * Unnecessarily increasing the attack surface: two protocols, two pieces of code -- not to mention protecting both, if you happen to care. * It becomes harder to troubleshoot stuff (what host is it? does it support slaac, dhcpv6, or both?... and all the inconsistent results being discussed in the slaac-problem I-D). (And, maybe less important, a "wt_?" moment for everyone that happens to be learning about or deploying IPv6, and happens to figure or come across any of the above three bullets) Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Jan 31 10:36:30 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E920D12948D for ; Tue, 31 Jan 2017 10:36:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=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 QKOZgLnv3Y-n for ; Tue, 31 Jan 2017 10:36:26 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id AAD50129531 for ; Tue, 31 Jan 2017 10:36:25 -0800 (PST) Received: from stereo.hq.phicoh.net ([::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #127) id m1cYdI0-0000GfC; Tue, 31 Jan 2017 19:36:24 +0100 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bF054DD66@u-1.phicoh.com References: <99204933-5CB6-4E89-BD6A-FD40136DF6F5@steffann.nl> <64592AC1-EFE9-4AA9-8C94-CF48986EC485@google.com> <892E650B-5F77-4FB9-B157-B84300E15CF6@fugue.com> <672582C8-BE04-4CF1-B26E-E8CF3235F6DB@google.com> <75027399-7127-4C8D-BAEA-4F3F923EC728@google.com> <43AB38C9-B4D8-4499-BA6F-B0C668F10554@fugue.com> In-reply-to: Your message of "Mon, 30 Jan 2017 03:06:48 -0300 ." Date: Tue, 31 Jan 2017 19:36:23 +0100 Archived-At: Cc: Fernando Gont Subject: Re: [v6ops] sidetrack on DNS-SD vs. DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 18:36:28 -0000 >* Unnecessarily increasing the attack surface: two protocols, two pieces >of code -- not to mention protecting both, if you happen to care. I'm not sure this is correct. At the moment you always need RA. Of course, if somebody just goes ahead and does a default router option in DHCPv6, RA could go away, but that is not the case at the moment. Unless we duplicate lots of DHCP options in RA, you probably need DHCP as well, for example to specify NTP servers. So realistically, every environment should run both RA and DHCP. Ideally, all hosts should support getting address both using SLAAC and using IA_NA, so hosts have to deal with the attack surface as well. Migrating to just RA will at some point replicate statefull DHCPv6 in RA, so that's certainly not ideal. Getting rid of RA is realively easy (that how IPv4 works) but will not be popular. So the dual attack surface seems something we just have to live with. From nobody Tue Jan 31 11:23:09 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D72A1299DB for ; Tue, 31 Jan 2017 11:23:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 u9roPnmgiMaa for ; Tue, 31 Jan 2017 11:23:06 -0800 (PST) Received: from mail-pf0-x243.google.com (mail-pf0-x243.google.com [IPv6:2607:f8b0:400e:c00::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80CFD1299D8 for ; Tue, 31 Jan 2017 11:23:06 -0800 (PST) Received: by mail-pf0-x243.google.com with SMTP id y143so29357812pfb.1 for ; Tue, 31 Jan 2017 11:23:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=GrfC87kSHQfjXqKGk/xCqZgmrVkJynSVFeGTm+t6ETI=; b=rcJBrMejq5EB+DBazhXoMNCr+VPgrQKsuT7SlG2p/qjZVciTqvqWkBm2BWTswB7vrT YtCb4C3hsLE50jqPj6m2euKV2vnjXMQLmXcvjcGATkPetmbHHjMOIsgy8WUL3f/7E5nI ymdxxOoC1bdRRVY8C/WUcrqB9jFP93fo/+b1i/lOdTHm9m+bQaIkXOlxrrIKc9Kkn63s U/ToT1O4DxvmL4pTpx7bV0wYCrCIQn8LLgAf41euS3MjbTBljyTDkwjjIaJ5so+Pdu0h yNy4Gu6O05lwc5mkAIMITAbLO1677adX6eVMyv9+HN+spGlFlALaoyhZewLUNIoXfRfc nQDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=GrfC87kSHQfjXqKGk/xCqZgmrVkJynSVFeGTm+t6ETI=; b=sGfdCWvQbzggwHCRpkpxhOR/5Qq/8bfmQQxstauHktH5mts4/tCUovszUBQ8J99QKf UwdWWfWhFqROMhTsfIIpq2YTz6M6ERgVZq9hGL2DKTtlPhlciu6UWeYL7C9Ut2DvpzUg sicOEyE0iKOvoONU1bzaVq2jxus3rDiZDcuTjKnTO1W131zGYwzcPRoqJo6lKTgHkgk+ KcG4PWAXKXOP15cBvl/D3u+vzJO1lcq9/0azU9qekzVuzduXSBBcyy5sGuTv1mQL99v/ WifN/dDG45DLKHfKPOizAols2Q/K+LtK1AvEUOn3CYo3oiIdZZn1/U7r4Yvbp2htUZrB /dYQ== X-Gm-Message-State: AIkVDXJ5i5I4Z7QP2CmXeIehVBMwoZZkWA2AtXLIpo1zbGk7E/ZDCLnxyWlJHs0BcEMn3w== X-Received: by 10.84.169.67 with SMTP id g61mr42207850plb.137.1485890585983; Tue, 31 Jan 2017 11:23:05 -0800 (PST) Received: from [192.168.178.21] (179.218.69.111.dynamic.snap.net.nz. [111.69.218.179]) by smtp.gmail.com with ESMTPSA id r78sm43116813pfe.55.2017.01.31.11.23.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Jan 2017 11:23:05 -0800 (PST) To: Philip Homburg , v6ops@ietf.org References: <99204933-5CB6-4E89-BD6A-FD40136DF6F5@steffann.nl> <64592AC1-EFE9-4AA9-8C94-CF48986EC485@google.com> <892E650B-5F77-4FB9-B157-B84300E15CF6@fugue.com> <672582C8-BE04-4CF1-B26E-E8CF3235F6DB@google.com> <75027399-7127-4C8D-BAEA-4F3F923EC728@google.com> <43AB38C9-B4D8-4499-BA6F-B0C668F10554@fugue.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <4cbc3c52-504f-7282-3e74-75772aa59094@gmail.com> Date: Wed, 1 Feb 2017 08:23:05 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Fernando Gont Subject: Re: [v6ops] sidetrack on DNS-SD vs. DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 19:23:07 -0000 On 01/02/2017 07:36, Philip Homburg wrote: ... > So realistically, every environment should run both RA and DHCP[v6]. It seems to me that there are plenty of running proofs that this is not true. Brian From nobody Tue Jan 31 11:26:25 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F3961299C2 for ; Tue, 31 Jan 2017 11:26:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 q1CJ-C7VBsNB for ; Tue, 31 Jan 2017 11:26:22 -0800 (PST) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9C8912955B for ; Tue, 31 Jan 2017 11:26:22 -0800 (PST) Received: by mail-pf0-x234.google.com with SMTP id e4so109749091pfg.1 for ; Tue, 31 Jan 2017 11:26:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=SJf8kdSxlA0xJFoxJteigDbYCCfPb2KsAMjxQKsJqQ0=; b=oCBatYgz91JFcE8DuphJ4rTV9CxY4rtM13i0LTckqLBP+mgqMgBw47/SueqdeNCnkO VPVfzh7zcctS1HVdDE/MXa7Icy8P8/4s4jkcXTPBs6ji3GAPumS9KmUyYcOaXMhrRKGf ooktmIRWPCWIudwk+KlI11kOdrpBlvFwNT6r5prMSNFWX8SRWlgJmHE0X6VO9mNd+vMv 5Nv8Y36uza4HR+VNfftoMSs6HHBfAQhE4UkJPSzjc9I5CHntYroeqzYkZG2h7WJXgRtc zQHY56NLmv6CTbVQUmbvIVV24RcSvKp9O3jtbhjRpkHerWWNKGBI0Yi/2d9cxKIDbYKe E23g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=SJf8kdSxlA0xJFoxJteigDbYCCfPb2KsAMjxQKsJqQ0=; b=CZE+Jnq+6shQHR744frI4DcMVnqVG/0WgKGzdYEwLRs1GmWUwoyFyEStmyn8Ecm92q XZKmljRJiTK6osxvB4ArP1pSQkLVgwGf5Ww5i0mwpihyYQyfRexdMvF20WKrm1Y6uFFk g3eYzNN5ezuNK6jUylokH4WneBcjjMSN2SnPmrOCWVxl26lXvp0usI56ECRX9pgBtNcp LSndt6CR/JbKS40+P9al6pGlZvh+UQQtP6Tn9ilM0tURQYDZGJ0XzViM6pOIIWlsrLaf j40i338Z22SjdgsSph4WdKaJcGt7fdeBNeCv7V76pNlIP1fg/unWZnbXSoXdsjT5euHy GI6Q== X-Gm-Message-State: AIkVDXIAal1T/imlEaqZXQvR8vMjo98WUkw5j5AdUiH4Ucj1muzBSM83zq74vzGSD2zEJw== X-Received: by 10.98.3.3 with SMTP id 3mr30886697pfd.95.1485890782193; Tue, 31 Jan 2017 11:26:22 -0800 (PST) Received: from [192.168.178.21] (179.218.69.111.dynamic.snap.net.nz. [111.69.218.179]) by smtp.gmail.com with ESMTPSA id p6sm43164414pfg.6.2017.01.31.11.26.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Jan 2017 11:26:21 -0800 (PST) To: Ron Bonica , IPv6 Ops WG References: From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Wed, 1 Feb 2017 08:26:21 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-considerations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 19:26:24 -0000 Ron, Thanks. But one nit surely: > - Recommend against ULA-only means - Recommend against ULA-only (except when disconnected from the Internet) Regards Brian On 01/02/2017 04:22, Ron Bonica wrote: > Folks, > > Some time ago, I queried the WG's disposition regarding draft-ietf-v6ops-ula-usage-considerations (https://mailarchive.ietf.org/arch/search/?email_list=v6ops&index=x6OmZJ1n2F0rBX6iq5GHRBHWRO0&gbt=1). I think that the consensus was: > > - Continue as informational > - Recommend against ULA-only > - Attempt to find some set of recommendations upon which the WG can agree. > > So, if the authors are so disposed, I encourage them to produce a new version of the draft, leveraging what we learned during this email thread. > > Ron > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Tue Jan 31 11:26:38 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFCA31299E0 for ; Tue, 31 Jan 2017 11:26:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.501 X-Spam-Level: X-Spam-Status: No, score=-7.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wpi.edu 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 JuFF8aSVNUZj for ; Tue, 31 Jan 2017 11:26:31 -0800 (PST) Received: from MAIL1.WPI.EDU (mail1.wpi.edu [130.215.36.91]) by ietfa.amsl.com (Postfix) with ESMTP id EB8F912955B for ; Tue, 31 Jan 2017 11:26:30 -0800 (PST) Received: from MAIL1.WPI.EDU (MAIL1.WPI.EDU [130.215.36.91]) by MAIL1.WPI.EDU (8.15.1/8.15.1) with ESMTP id v0VJQUDd015609 for ; Tue, 31 Jan 2017 14:26:30 -0500 DKIM-Filter: OpenDKIM Filter v2.10.3 MAIL1.WPI.EDU v0VJQUDd015609 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wpi.edu; s=_dkim; t=1485890790; bh=viGPYD98ssnhf7pnCcZSB5VzUd4GYEf5b1Z6nWnI9+E=; h=Date:From:To:Subject:References:In-Reply-To; b=e2B036/j8ZXwjyr6ERDU84oanIy4I0nqDs/X4oEiLotn6qA/tRTIkIyu5ipzA6rQZ SCYeP86T6Jw7uUdytjaJwCipYMOgpuGXn1GeQhUrVAn9hPMJmeTQWHBS+gsraA7eqW Be2H8G8Qys6zvJ0cz+vTxK71MgkiWglCzXyd6Kx8= Received: from milter1.wpi.edu (milter1.wpi.edu [130.215.36.49]) by MAIL1.WPI.EDU (8.15.1/8.15.1) with ESMTP id v0VJQUT8015606 for ; Tue, 31 Jan 2017 14:26:30 -0500 Received: from angus.ind.wpi.edu (angus.ind.wpi.edu [130.215.130.21]) by milter1.wpi.edu (8.14.4/8.14.4) with ESMTP id v0VJQTuU023397 for ; Tue, 31 Jan 2017 14:26:30 -0500 (envelope-from cra@WPI.EDU) Received: by angus.ind.wpi.edu (Postfix, from userid 10002) id 483D6DEE1C; Tue, 31 Jan 2017 14:26:29 -0500 (EST) Date: Tue, 31 Jan 2017 14:26:29 -0500 From: Chuck Anderson To: v6ops@ietf.org Message-ID: <20170131192629.GN3933@angus.ind.wpi.edu> References: <672582C8-BE04-4CF1-B26E-E8CF3235F6DB@google.com> <75027399-7127-4C8D-BAEA-4F3F923EC728@google.com> <43AB38C9-B4D8-4499-BA6F-B0C668F10554@fugue.com> <4cbc3c52-504f-7282-3e74-75772aa59094@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4cbc3c52-504f-7282-3e74-75772aa59094@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-PerlMx-Spam: Gauge=X, Probability=10%, Report=' TO_IN_SUBJECT 0.5, HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1000_LESS 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_400_499 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, FROM_EDU_TLD 0, IN_REP_TO 0, LEGITIMATE_SIGNS 0, MSG_THREAD 0, NO_CTA_URI_FOUND 0, NO_URI_FOUND 0, NO_URI_HTTPS 0, REFERENCES 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CD 0, __CT 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __HAS_FROM 0, __HAS_MSGID 0, __IN_REP_TO 0, __MIME_TEXT_ONLY 0, __MIME_TEXT_P 0, __MIME_TEXT_P1 0, __MIME_VERSION 0, __NO_HTML_TAG_RAW 0, __PHISH_SPEAR_STRUCTURE_1 0, __REFERENCES 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __SUBJ_ALPHA_NEGATE 0, __TO_IN_SUBJECT 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __USER_AGENT 0' Archived-At: Subject: Re: [v6ops] sidetrack on DNS-SD vs. DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 19:26:37 -0000 On Wed, Feb 01, 2017 at 08:23:05AM +1300, Brian E Carpenter wrote: > On 01/02/2017 07:36, Philip Homburg wrote: > ... > > So realistically, every environment should run both RA and DHCP[v6]. > > It seems to me that there are plenty of running proofs that this > is not true. It seems impossible to have an IPv6-only environment that supports general usage devices (BYOD) where this CAN'T be true. From nobody Tue Jan 31 12:46:37 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12E2A129590 for ; Tue, 31 Jan 2017 12:46:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.058 X-Spam-Level: X-Spam-Status: No, score=-3.058 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com 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 aGmUy24z5Y0y for ; Tue, 31 Jan 2017 12:46:34 -0800 (PST) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0093.outbound.protection.outlook.com [104.47.34.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7268012959F for ; Tue, 31 Jan 2017 12:46:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=d8NFEHhwsz6qRh+nXsG6kWl6bMLbQWg/Uob7P8E1b9w=; b=UupW/bdtwfbioABJiKYm1i1oPVjRErUGygaholorm/JyMFPBH7WzJTCLXHbYHZ/pzqLHO/c/mKgOec9eVgedfZN7nwJE2pqz1SxJSj+tUQh3kdwFWXQLxmZwpcS7SC/9/Qy8nWhKYXxN3t15UkBkTpcnhahTMgn2kgGjiJ3zMWo= Received: from BLUPR0501MB2051.namprd05.prod.outlook.com (10.164.23.21) by BLUPR0501MB2049.namprd05.prod.outlook.com (10.164.23.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.874.6; Tue, 31 Jan 2017 20:46:33 +0000 Received: from BLUPR0501MB2051.namprd05.prod.outlook.com ([10.164.23.21]) by BLUPR0501MB2051.namprd05.prod.outlook.com ([10.164.23.21]) with mapi id 15.01.0874.020; Tue, 31 Jan 2017 20:46:33 +0000 From: Ron Bonica To: Brian E Carpenter , IPv6 Ops WG Thread-Topic: [v6ops] draft-ietf-v6ops-ula-usage-considerations Thread-Index: AdJ71bub1L6aUKYaSxmQB+Og32Va4wAIitmAAALHifA= Date: Tue, 31 Jan 2017 20:46:33 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rbonica@juniper.net; x-originating-ip: [66.129.241.12] x-ms-office365-filtering-correlation-id: d935529e-5946-4da9-e616-08d44a1a3e11 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401078); SRVR:BLUPR0501MB2049; x-microsoft-exchange-diagnostics: 1; BLUPR0501MB2049; 7:BBtFalmVpDIryL3UzKyitN0sToL/sqm2Q/l9hZCYjplSdQMLHYmoFPI1nqaGmdIipC+yuIzBTdkjUa02+cNQZZL6K38BLdAwqBDm0QhbZB2SGqupPrxWADIG6nwOCHs2Z3Wd+/RMF8PwKHAjR3clF1N89TVwbnADn29js7zA3qU1P8CM1lDGUyYoAgBH8gNUeUwhHdZ9tukqn/EqgFJlg/PGSYXlU88tTpEPLz4wF5eO/Pp9ruu4eqk+Qt1xE5u7zf7n9M3OixF7WDeTAVmg6LUT/5EzTIdSwjxV26UOuAADqZI2fbQISJ5zcalws1LFKvt4sPg8MAkclyv+gugJDYV/XqN9iiHO4FuAG46ks95Xtzca41a/XsbyPUiy3/WjXxrM1qU2+Gi7aNa6H57ZvzaSmQZ59XYdgRqzuzS1dEpxqzelqqtKIK5/8zhC1kjfFsZJnt3R0RkcDMDFds/lsVMz6gCmJUDVxQ054VP3MfTep5PWLzsRbuRfgBHnBfB0nSCw+I6zGnFyPg1QILOwL4oAnwruYi8k8T6S0rxe/yu4s3Jm4GTKBNnF/wYTMD/Z x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123564025)(20161123562025)(20161123560025)(20161123555025)(6072148); SRVR:BLUPR0501MB2049; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB2049; x-forefront-prvs: 0204F0BDE2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39850400002)(39450400003)(39860400002)(39410400002)(39840400002)(377454003)(51444003)(24454002)(13464003)(199003)(189002)(86362001)(7736002)(53936002)(68736007)(92566002)(230783001)(305945005)(8676002)(575784001)(9686003)(74316002)(81156014)(6306002)(55016002)(99286003)(8936002)(81166006)(3280700002)(76176999)(25786008)(6436002)(2950100002)(38730400001)(5660300001)(39060400001)(66066001)(7696004)(6506006)(54356999)(229853002)(189998001)(107886002)(5001770100001)(2906002)(2900100001)(3846002)(106356001)(101416001)(33656002)(97736004)(122556002)(105586002)(3660700001)(77096006)(6116002)(102836003)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB2049; H:BLUPR0501MB2051.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jan 2017 20:46:33.6110 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB2049 Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-considerations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 20:46:36 -0000 QWNrLiBVTEEtb25seSBpcyBPSyB3aGVuIGRpc2Nvbm5lY3RlZCBmcm9tIHRoZSBJbnRlcm5ldC4N Cg0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQnJpYW4gRSBDYXJw ZW50ZXIgW21haWx0bzpicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb21dDQo+IFNlbnQ6IFR1ZXNk YXksIEphbnVhcnkgMzEsIDIwMTcgMjoyNiBQTQ0KPiBUbzogUm9uIEJvbmljYSA8cmJvbmljYUBq dW5pcGVyLm5ldD47IElQdjYgT3BzIFdHIDx2Nm9wc0BpZXRmLm9yZz4NCj4gU3ViamVjdDogUmU6 IFt2Nm9wc10gZHJhZnQtaWV0Zi12Nm9wcy11bGEtdXNhZ2UtY29uc2lkZXJhdGlvbnMNCj4gDQo+ IFJvbiwNCj4gDQo+IFRoYW5rcy4gQnV0IG9uZSBuaXQgc3VyZWx5Og0KPiANCj4gPiAtIFJlY29t bWVuZCBhZ2FpbnN0IFVMQS1vbmx5DQo+IA0KPiBtZWFucw0KPiANCj4gLSBSZWNvbW1lbmQgYWdh aW5zdCBVTEEtb25seSAoZXhjZXB0IHdoZW4gZGlzY29ubmVjdGVkIGZyb20gdGhlDQo+IEludGVy bmV0KQ0KPiANCj4gUmVnYXJkcw0KPiAgICBCcmlhbg0KPiANCj4gT24gMDEvMDIvMjAxNyAwNDoy MiwgUm9uIEJvbmljYSB3cm90ZToNCj4gPiBGb2xrcywNCj4gPg0KPiA+IFNvbWUgdGltZSBhZ28s IEkgcXVlcmllZCB0aGUgV0cncyBkaXNwb3NpdGlvbiByZWdhcmRpbmcgZHJhZnQtaWV0Zi12Nm9w cy0NCj4gdWxhLXVzYWdlLWNvbnNpZGVyYXRpb25zDQo+IChodHRwczovL21haWxhcmNoaXZlLmll dGYub3JnL2FyY2gvc2VhcmNoLz9lbWFpbF9saXN0PXY2b3BzJmluZGV4PXg2T21aSg0KPiAxbjJG MHJCWDZpcTVHSFJCSFdSTzAmZ2J0PTEpLiBJIHRoaW5rIHRoYXQgdGhlIGNvbnNlbnN1cyB3YXM6 DQo+ID4NCj4gPiAtIENvbnRpbnVlIGFzIGluZm9ybWF0aW9uYWwNCj4gPiAtIFJlY29tbWVuZCBh Z2FpbnN0IFVMQS1vbmx5DQo+ID4gLSBBdHRlbXB0IHRvIGZpbmQgc29tZSBzZXQgb2YgcmVjb21t ZW5kYXRpb25zIHVwb24gd2hpY2ggdGhlIFdHIGNhbg0KPiBhZ3JlZS4NCj4gPg0KPiA+IFNvLCBp ZiB0aGUgYXV0aG9ycyBhcmUgc28gZGlzcG9zZWQsIEkgZW5jb3VyYWdlIHRoZW0gdG8gcHJvZHVj ZSBhIG5ldw0KPiB2ZXJzaW9uIG9mIHRoZSBkcmFmdCwgbGV2ZXJhZ2luZyB3aGF0IHdlIGxlYXJu ZWQgZHVyaW5nIHRoaXMgZW1haWwgdGhyZWFkLg0KPiA+DQo+ID4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSb24NCj4gPg0KPiA+DQo+ ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiA+IHY2b3BzIG1haWxpbmcgbGlzdA0KPiA+IHY2b3BzQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KPiA+DQo=